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I. INTRODUCTION 



A. BACKGROUND 



The United States Congress mandated in the 1992 Department of Defense (DOD) 
Appropriation Act that: 

“None of the funds appropriated in this Act may be used to fill the Commander’s 
position at any military medical facility with a health care professional unless the 
prospective candidate can demonstrate professional administrative skills. ” [Ref. 1 ] 

In response to this mandate, the Deputy Surgeon General of the Navy established a 
partnership between the Bureau of Medicine and Surgery (BUMED) and the Naval 
Postgraduate School (NPS) to develop a comprehensive competency-based educational 
program for the U. S. Navy’s senior health care executives. This initiative has taken the 
form of the Executive Management Education (EME) Program. 



1. What is EME? 

The EME Program is an executive medical education curriculum consisting of 49 
course modules and 410 hours of instruction. The syllabus was developed over an 18 
month period by subject matter experts at NPS after a careful analysis of the core 
competencies required in the field of health care administration. [Ref. 2] To date, DOD 
has defined 44 administrative competencies across nine competency categories that 
pertain specifically to health care administration. The BUMED/NPS team started with 
these competencies and completed a detailed needs assessment to identify those skills 
which the Navy’s senior medical officers felt were most important to effectively manage 
a military medical treatment facility (MTF). The current EME Program curriculum was 
built around the findings of that needs assessment. The curriculum, however, is not static 
and future expansion to meet the remaining DOD defined competencies is underway -- 
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particularly in regard to changing business practices associated with DOD health care 
reform initiatives (TRICARE). 

The objective, then, of the EME Program is to educate senior military health care 
executives to achieve those specifically defined administrative skills and competencies 
that have been determined a prerequisite for command of major DOD MTFs or other 
complex health care delivery systems. 

Implementation of the EME curriculum is as follows. Teams of NPS faculty 
members travel to MTFs around the world to provide blocks of instruction covering the 
various competency categories. Because it is fiscally and operationally impractical to 
educate all of the Navy’s prospective health care leaders in one central location, these 
presentation teams spend a considerable amount of time “on the road” teaching course 
modules so that the disruption to MTF day to day operations is minimized. While on-site 
delivery of course modules by NPS faculty is the current pedagogy, the future use of a 
distributed educational system such as videotele-education (VTE) and 
videoteleconferencing (VTC) is a viable alternative format for some of the course 
modules. 



2. Why EMETRAK? 

As the program matures, many offices within the Department of the Navy will be 
interested in the EME program enrollment status of selected officers. These entities will 
range from Medical Department specialty advisors, detailers, and promotion boards to the 
Corps chiefs as they assess an officer’s specific administrative skills and qualifications 
preliminary to assignment or promotion decisions. Progress towards completion of the 
EME program will, in the future, be viewed as a commitment to attaining the necessary 
competencies required for command of a Navy MTF. For this very reason, an accurate 
and up-to-date record of EME course completion is critical. Moreover, due to the 
comprehensive nature of the EME program, it may take several years for an officer to 
complete the entire curriculum. Therefore, officers will move to new duty stations and 
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serve in many different billets while enrolled in the program. In spite of the officer career 
dynamics, the Navy will require that an accurate cumulative record of attained 
competencies be maintained. This concept is the basis for the Executive Management 
Education Tracking (EMETRAK) system. 

The EME program manager located at the Naval School of Health Sciences 
(NSHS) in Bethesda, MD and the EME program coordinator at NPS have indicated that 
an information system supporting the EME Program should have the following 
characteristics: 

• Provide a consolidated record of all eligible Navy medical department officers 
(Medical, Medical Service, Nurse and Dental Corps), their billet and 
command information, and the specifics of each course taken within the EME 
program. 

• Officer demographics data in the system must be capable of being updated by 
the officer’s command or through information provided directly by the Bureau 
of Naval Personnel (BUPERS). 

• EME course completion data should input at the officer’s command, a third- 
party training site, by the EME program coordinator’s staff at NPS, or by the 
EME program manager’s staff at the NSHS. 

• A “robust” query and reporting capability on the officers enrolled in the EME 
program. 

• The officer’s integrated educational record must be made available to all 
personnel agencies providing career mentoring to medical department officers 
or making decisions about officer career planning. 

• A future expansion capability to enable remote access and viewing of officer 
records by responsible agencies. 

The characteristics described in this section serve as a starting point for further 
study of system requirements. 
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B. 



PURPOSE OF RESEARCH 



The purpose of this research is to conduct a thorough study of the information 
requirements for a system that supports the EME program and to recommend an 
implementation plan that adequately satisfies those needs. 



C. METHOD 

The Systems Development Life Cycle (SDLC) provides a logical methodology 
for developing and maintaining an information technology (IT) solution. The SDLC is a 
project management tool used to plan, execute, and control an IT systems development 
project. SDLC consists of five phases: Systems Analysis, Systems Definition, Systems 
Design, Systems Implementation, and Systems Support. [Ref. 3] The cycle begins with 
the Systems Analysis phase in which a business problem and an information architecture 
to solve the business problem are defined. During the next phase, Systems Definition, the 
user requirements are closely analyzed and a logical design for information flow and data 
modeling are proposed. Systems Design, the third phase, involves the evaluation of 
alternative solutions and the physical design of an information system. The fourth step is 
the Systems Implementation phase which encompasses the construction and testing of the 
production system. The final phase, Systems Support, involves ongoing maintenance and 
recommendations for system improvement. The SDLC will be used as a guide for the 
development of an information system to support the business needs of the EME 
program. 



D. SCOPE OF RESEARCH 

The study will focus on the following research questions in its examination of 
possible solutions for EMETRAK: 
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1. Who are the EMETRAK system owners and users and what are their 
information requirements? 

2. What type of information system will support the future needs of the EME 
program? 

a. A single-user personal computer (PC) based database application? 

b. A multi-user database architecture implemented over a local area 
network? 

c. A multi-user database architecture implemented over a wide area 
network? 



3. What system processes are necessary to track the administrative educational 
records of all EME eligible Navy Medical Department officers? 

4. Once a computer solution is selected, what features of contemporary database 
management system applications are desired for the EMETRAK system? 



5. What are the design issues for the candidate system? 

a. What will the conceptual data model look like? 

b. What will the process model look like? 

c. How will data be updated? 

d. What type of architecture will support the process and data 
models? 



e. What are the data and system security issues? 

f. What are the system inputs and outputs? 

g. What type of queries are required? 

h. Will the database architecture be scaleable and support future 
growth? 
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This study will involve a detailed examination of the feasibility, costs, benefits, 
process and data requirements of developing an operational database management 
system. Requirement specifications for a prototype database application will also be 
developed. The end product will be a prototype database application developed from the 
requirement specifications using the Microsoft Access 2.0® relational database 
application. The study concludes with recommendations for implementing a remotely 
accessed multi-user database application. 



E. THESIS ORGANIZATION 

The thesis is organized into seven chapters and eleven appendices. Chapter II 
discusses the Systems Analysis phase and includes an initial feasibility study of the 
proposed system. Chapters III, IV, and V address definition, design and implementation 
issues, respectively, for the prototype system (Phase I). Chapter VI discusses analysis 
and definition issues for a multi-user system (Phase II). Lessons learned during each 
phase of the SDLC are included in the appropriate chapters. Conclusions and 
recommendations are provided in Chapter VII. Existing system network topologies, 
process models, prototype queries, and reports are included as appendices to the study. 
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II. SYSTEMS ANALYSIS PHASE 



A. METHOD 

The Systems Analysis phase began with an initial investigation of the business 
environment. The EME program manager, EME program coordinator, and selected NPS 
Systems Management faculty were interviewed to determine the project scope and system 
boundaries. A questionnaire (Appendix A) was the primary tool used during the initial 
interviews to help define the problem and gain an understanding of the people, data, 
activity, and networking requirements of the proposed system. NPS staff studies and 
EME program documentation were consulted to provide insight into the history and goals 
of the executive education program. The EME course catalog provided curriculum 
information and described the competency categories. A problem statement and system 
requirements were developed from the information gathered during the initial 
investigation. 



B. PROBLEM STATEMENT 

The EMETRAK system is to provide an integrated educational record on all Navy 
medical department officers in the grade of 0-3 (LT) and above enrolled in the EME 
curriculum. This entails tracking approximately 11,300 officers located in 13 Health 
Service Regions (HSR) around the world (Figure 1) and officers assigned to operational 
units (ships, deployed units, etc.). The record must be made available to the officer and 
those personnel agencies responsible for providing officer career planning decisions 
(BUMED, BUPERS). The system must be flexible enough to handle a highly transient 
population and different course modules from a variety of executive education sources 
outside of the EME curriculum. The long-term requirement for the system is for 
distributed access to officer information from various sites including all major Navy 
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medical treatment facilities (MTF), regional training sites, curriculum sponsors, BUMED, 
BUPERS, and the EME Program staff for a total of 71 end-user sites. Table 1 shows the 
number of anticipated end-user sites for a distributed system and Appendix B contains a 
detailed listing of the MTFs which would have EMETRAK terminals. 



Agency 


Number 


Medical Treatment Facilities 


55 


BUMED 


5 


BUPERS 


3 


NSHS, Bethesda, MD 


3 


NPS 


5 


Total 


71 


Table 1 . Proposed Number o 


f End-user Sites 



C. SCOPE 

The proposed information system will collect, maintain, collate, and report all 
information required by the EME program. This includes information gathered by the 
program manager at the Naval School of Health Sciences (NSHS) in Bethesda, MD, the 
program coordinator at NPS, individual commands, BUPERS, BUMED, and other 
external training sources granting continuing education unit (CEU) credits. The scope of 
the EMETRAK system will be limited to the business functions of the EME program 
and, consequently, no effort is foreseen to consolidate the tracking requirements of other 
professional medical education programs. However, the backbone of this system could 
suggest additional future applications. 
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12 ' V 



Figure 1. DOD Health Service Regions [After Ref. 4, p. 8] 
Note: HSR 13 refers to overseas commands 



1. System Owner and Users 

a. System Owner 

The initial project management responsibilities for the development of the 
proposed information system has been assigned to the EME program coordinator at NPS 
by the EME program manager at NSHS, Bethesda. The program coordinator is 
considered to be the EMETRAK system owner for the purpose of this study. 

b. System Users 

The information system will directly affect the following users: 

• EME program manager and the staff at NSHS, Bethesda, MD. 

• EME program support staff at NPS 
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• Staff Education and Training Departments of Navy MTFs 

• Personnel Departments of Navy MTFs 

• BUMED Planning and Programming Divisions 

• Medical Department Specialty Advisors 

The information system will indirectly affect the following users: 

• Medical Department Corps Chiefs and their offices 

• BUPERS 

• All Navy medical department officers (0-3 and above) in the 
Medical, Medical Service, Nurse, and Dental Corps 



2. Context Diagram 

A context diagram defines the boundary of a system-in-focus, identifies its key 
external entities, and the interaction between the two. [Ref. 5, p. 221] The EMETRAK 
context diagram (Figure 2) depicts BUMED, BUPERS, the MTFs, the Corps chiefs, 
NSHS, and the EME program staff as external entities to the internal functionality of the 
EMETRAK system-in-focus. The diagram also illustrates the anticipated interactions, in 
terms of inputs and outputs, between the external entities and the EMETRAK system. 



3. Internal Entities 

Internal entities are objects within a closed system about which the system owner 
desires to collect data. Within EMETRAK, there are five major entities: OFFICER, UIC, 
CLASS, COURSE, and COMPETENCY. 

• OFFICER - OFFICER refers to any medical department officer (grade 
0-3 and above) with the designator of 2100 (Medical Corps), 2200 (Dental 
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Corps), 2300 (Medical Service Corps), or 2900 (Nurse Corps) enrolled in 
the EME program. 

• UIC - UIC refers to the unit identification code which is a unique 
numerical designation for a DOD medical treatment facility. 

• CLASS - A CLASS is an instance of an EME eligible officer taking a 
course module. 

• COURSE - A COURSE is one of the course modules designated in the 
EME curriculum. 

• COMPETENCY - COMPETENCY refers to a competency category 
specified in the EME course catalog. 




(SUMMARY BY COMPETENCY 
AND CORPS) 



Figure 2. EMETRAK Context Diagram 



11 



D. INFORMATION SYSTEM FUNCTIONS 



1. Desired Functions 

• Ability to add, delete, modify, display, and automatically update 
related fields 

• Ability to search and query the database for records based on a variety 
of selection criteria 

• Ability to print screens and reports as desired by the users to satisfy 
local, higher echelon, and other on-demand requirements 

• Ability to print officer transcripts and completion certificates 



2. Data To Be Tracked 

• Officer Information - Social Security Number (SSN), name, rank, 
billet sequence code (BSC) number, designator, job title, command 
unit identification number (UIC) and electronic mail address 

• Command Information - UIC number, address, commercial telephone 
number. Defense Switched Network (DSN) telephone number, HSR 
number 

• Course Information - Course ID number, course name, course length 
in hours, CEU credit hours, competency classification, and course 
sponsor 

• Competency Information - Competency title and course assigned to 
that competency 

• Class Information - SSN of the officer, course ID number, class date, 
class location, class instructor, and host command 



12 



3. 



Queries To Be Generated 



System queries are divided into three major categories: structured, interactive, and 
statistical queries. Structured queries are standardized pre-coded queries which require 
no user input other than selecting the actual query. Structured queries should focus on 
providing a browse function for the data in different representations. Interactive queries 
should be more flexible and provide a narrower cross-sectional view of the data based 
upon the criteria input by the user. Statistical queries should be designed to provide 
statistical and demographic summaries of the database for the purposes of program 
management rather than for viewing data. 

a. Structured Queries 
Structured queries should include: 

• All officers in alphabetical order 

• All officers sub-divided by command 

• List of all UICs 

• List of all EME courses 

• List of all course titles by competency category 

• List of all course modules provided in the last 30/60/90 days 

b. Interactive Queries 
These should include: 

• All officers and course modules competed in a specified 
command (user inputs UIC) 

• List of all officers satisfying a specific profile (user inputs one 
or all of: rank, HSR, competency, designator) 
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• List of course modules and hours completed by a specific 
officer (user inputs SSN) 

c. Statistical Queries 

Statistical queries should include: 

• The number of officers that have attained each competency 

• The number of students within each HSR enrolled in EME 

• The percentage of officers that have completed each 

competency category within each UIC 

• The percentage of officers that have completed each 

competency category, sub-divided by rank 

• The number of officers that have completed each competency 
category 



4. Reports To Be Generated 

EMETRAK must be capable of generating reports based upon the structured and 
interactive queries that have been mentioned in the previous section. The reports desired 
by the system owner include the following: 

• Alphabetical roster of all enrolled officers and the course modules that 
they have completed 

• Alphabetical roster of officers, sub-divided by command, and the 
course modules that each has completed 

• Mailing list of all participating commands 

• List of all EME course modules by competency category 

• Course completion letters 
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• Course completion certificates 

• Officer transcripts 



E. PROJECT PHASES 

The proposed system is straight-forward in its business rules, logical architecture, 
input/output and report generation requirements. What sets it apart is the system owner’s 
desire to implement a low cost interactive system distributed over a wide area. Further, 
the system owner desires an initial data storage, information retrieval, and reporting 
capability within 60 days of project commencement because of the frequency with which 
courses will be delivered during the last quarter of FY-95. These requirements lend 
themselves to a two-phased approach for system development. Phase I is envisioned as a 
single-user personal computer (PC) based database application developed using a fourth 
generation language (4GL) and rapid prototyping techniques. Phase II migrates all 
functionality of the single-user system to a widely distributed multi-user environment 
using the existing Navy Medical Department Network (NMDN) as a backbone. 



F. FEASIBILITY 

The feasibility analysis is a cross life cycle activity that must be continuously 
performed throughout the systems development process. [Ref. 5, p. 812] The initial 
assessment is performed to measure the urgency of the problem and determine if further 
detailed study of the problem is warranted. A more detailed study of the problem, its 
opportunities, and constraints is completed during the Systems Analysis phase of the 
SDLC and will be discussed in the next chapter. The feasibility analysis is guided by the 
following tests: political, operational, economic, technical, and schedule feasibility. 
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1 . 



Political Feasibility 



It is clear from the congressional mandate that today’s taxpayer has the same 
expectation of health care administration in the Defense Department, with respect to 
quality and cost containment, as they do of the private sector. These expectations lead to 
a new era in which DOD must better prepare its medical leadership for the future 
challenges of health care management. This new climate of educating the prospective 
commanders in specific health care related administrative skills and competencies 
formalizes what has, in the past, been an informal process left to the individual medical 
department officer. As with any change effort, the idea of having a formal requirement 
for executive education will undoubtedly meet some initial resistance. However, since 
the Surgeon General of the Navy has given strong support to the EME concept and there 
are strong budgetary implications associated with the successful implementation of such a 
program, Navy-wide acceptance is all but assured. Language in the DOD Authorization 
Act for FY-96 further directs executive education activities in support of TRICARE 
program implementation - both for Lead Agent commanders and their HSR MTF support 
personnel. [Refs. 6, 7] 

The EME program management staff views the current climate as an opportunity 
to provide quality, cost effective executive education not only to those prospective MTF 
commanders, but also to the larger population of medical officers thereby increasing the 
overall competency of the Navy’s medical professionals. An effective information 
system, with the capabilities envisioned for EMETRAK, that captures the 
accomplishments of program participants and directly involves them in their educational 
process will accelerate initial acceptance of the EME program within the Navy’s medical 
community. 



16 



2 . 



Operational Feasibility 



Operational feasibility is a measure of how well a solution to a problem will work 
in an organization. This section examines the anticipated level of acceptance of an 
automated solution for the EME program. 

The program manager anticipates that during the final quarter of FY-95 65 hours 
of formal instruction will be provided and 270 officers will be enrolled in the program. 
That number is expected to triple during FY-96 and will steadily increase over the next 
several years. Clearly, automating the process of recording instances of EME instruction, 
producing program reports, and officer transcripts is justified given the anticipated 
frequency of course delivery and volume of data in the future. 

Implementation of any new information system presents operational challenges. 
While the routine recording of basic officer information, course modules, and class 
rosters at the EME program office will offer no serious challenges, the periodic import of 
officer personnel information from the BUPERS database, the regular distribution of 
program information to the various customer sites, and remote access to the database over 
a wide area network (WAN) by those customer sites is a bit more difficult. For these 
reasons, separating the functional design of Phase I from the challenges of remote access 
in Phase II Eire necessary. 



a. Data Import 

The officers who participate in the EME program are highly transient. 
They can expect to move to a new duty station a minimum of every three years. 
Therefore, the officer data file in the EMETRAK database will require frequent updating 
in order to maintain data accuracy. In order to accomplish this requirement, the Officer 
Master file from BUPERS could be used as a source to update EMETRAK officer 
information. The frequency of update is anticipated to be a monthly requirement and an 
agreement between the EME program staff and BUPERS for the recurring download of 
medical department officer data is being coordinated. 
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b. Remote Access 

Navy Medicine maintains a three-tiered hierarchical network infrastructure 
known as the Navy Medical Department Network (NMDN). The NMDN is composed of 
a wide area network (WAN), a series of metropolitan area networks (MAN) and local 
area networks (LAN). The WAN uses the existing Defense Information Systems Network 
(DISN), formerly known as the Defense Data Network (DDN), a packet switched 
network conforming to the Consultative Committee for International Telegraphy and 
Telephony (CCITT) X.25 protocol to provide connectivity between each MAN. The 
MANs are centered around major regional medical installations. Within each MAN are 
interconnected Ethernet local area networks (LANs) which conform to IEEE 802.3 
standards and support local MTF operations. Remote access to EME program 
information is feasible in Phase I through plain old telephone service (POTS), facsimile, 
electronic mail, electronic file transfer, and World Wide Web (WWW) access. A study 
of the existing NMDN topologies reveals that in a Phase II implementation the remote 
access options to EMETRAK data include: dial-in access using a modem, WWW 
applications, and the use of client-server applications over DISN. 



c. User A cceptance 

Observation of the EME Management Group during their normal office 
routine reveals that they are intelligent and literate personal computer users. They are 
familiar with the Windows® operating environment and Windows-compatible 
applications. The selection of a commercial-off-the-shelf (COTS) Windows-compatible 
database application seems a preferable solution for Phase I because of the familiarity of 
the EME support staff with the Windows® graphical user interface and its functionality. 
Familiarity with the application environment and confidence in its interoperability with 
other EME program office applications will enhance end-user acceptance of any software 
solution provided as part of Phase I. 
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The hope for Phase II is to migrate the functionality of the Phase I single-user 
application to a multi-user environment with an EMETRAK application interface 
residing at each MTF and other sites exercising managerial responsibility for the 
program. Acceptance of an EMETRAK application by this larger end-user population 
will require that the application be compatible with other MTF software applications, 
have a familiar graphical user interface, and have acceptable response time over the 
network. A survey of Navy MTF office automation products shows that the Windows® 
version of Microsoft Office Professional 4.3 is the office automation standard. This 
integrated package provides Microsoft Word 6.0® for word processing, Excel 5.0® for 
spread sheet functions, Powerpoint 4.0® for presentations, and Access 2.0® for database 
functions. A Windows® application which is compatible with the current integrated suite 
standard or uses one of its resident applications will certainly enhance acceptance of the 
Phase II product. 



3. Economic Feasibility 

A separate cost-benefit analysis was completed to measure the cost effectiveness 
of the project and portions of that analysis are provided in this section to show the 
relative merits of the proposed options. [Ref. 8] 



a. Costs 

The options considered were 1) a completely manual system, 2) a single 
user database management system (DBMS) with manual input/output/information 
exchange which represents Phase I functionality, and 3) a multi-user DBMS with 
distributed access via the Internet which represents Phase II functionality. The analysis 
began by identifying the tasks required to successfully implement a manual record- 
keeping and tracking system for the program. These tasks were measured in person- 
hours and the manual system was then used as a baseline from which to compare the 
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relative costs of two automated solutions. Standard government wage rates provided by 
the NPS Human Resource Office and adjusted by the requirements of the Navy 
Comptroller’s manual were used for calculating personnel costs for each alternative. The 
cost of each alternative was sub-divided into non-recurring costs which considered 
activation or start-up costs and recurring or operating costs. The total cost of each 
alternative was then discounted at the government standard rate of ten percent for a 
period of seven years to achieve a present value figure which could be compared. 

Project size, development time, and average staff size requirements for the 
development of the applications in Alternatives two and three were estimated using 
Function Point analysis and the Constructive Cost Model (COCOMO) in the organic and 
semi-detached modes, respectively. According to the models, the single user system 
(Alternative 2 - Phase I) was a 2100 lines of code project which could be developed in 
5.23 person-months with an average staff size of 1.33 persons. The models estimated that 
the multi-user system (Alternative 3 - Phase II), a slightly more complex project with 
over 3130 lines of code, could be completed with an average staff size of 1.88 persons in 
5.75 months. These figures were the basis for the non-recurring project development cost 
calculations after standard wage rates were applied. 

Tables 2 through 4 summarize the present value costs of the three 
alternatives discussed in the cost-benefit analysis. The cash flow figures in the tables 
include both non-recurring and recurring costs. From the tables it is apparent that the 
manual system (Alternative 1) is the most expensive option in terms of present value. 
The reason for this higher figure is the increased annual operating cost incurred because 
the manually intensive system requires more person-hours to maintain a given set of 
records than do the other two options. 

The single user system (Table 3) reflects a higher initial investment in 
Year 0 than does Alternative 1 because this option requires hardware and software, but 
the annual operating costs as a result of implementing the system are projected to be 
significantly less than the manual system. 
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Year 


0 


1 


2 


3 


4 


5 


6 


7 


Cash Flow 


$ 32,301 


$ 130,248 


$ 130,248 


$ 130,248 


$ 130,248 


$ 130,248 


$ 130,248 


$ 130,248 


PV Factor 


1.0 


0.909 


0.826 


0.751 


0.683 


0.621 


0.564 


0.513 


Present Value 


$ 32,301 


$ 118,407 


$ 107,642 


$ 97,857 


$ 88,961 


$ 80,873 


$73,521 


$ 66,837 


Total PV 


$ 666,400 



Table 2. Present Value of Alternative 1 Costs 



Year 


0 


1 


2 


3 


4 


5 


6 


7 


Cash Flow 


$ 71,702 


$ 67,074 


$ 67,074 


$ 67,074 


$ 67,074 


$ 67,074 


$ 67,074 


$ 67,074 


PV Factor 


1.0 


0.909 


0.826 


0.751 


0.683 


0.621 


0.564 


0.513 


Present Value 


$71,702 


$ 60,976 


$ 55,433 


$ 50,393 


$45,812 


$41,647 


$ 37,861 


$34,419 


Total PV 


$ 398,242 



Table 3. Present Value of Alternative 2 Costs 



Alternative 3 requires an even higher initial investment than does 
Alternative 2 because of higher development costs and increased complexity with respect 
to operating system, application software, and hardware requirements. The annual 
operating costs are also anticipated to be higher than Alternative 2, however, they are still 
much less than Alternative 1. 



Year 


0 


1 


2 


3 


4 


5 


6 


7 


Cash Flow 


$ 157,660 


$ 80,238 


$ 80,238 


$ 80,238 


$ 80,238 


$ 80,238 


$ 80,238 


$ 80,238 


PV Factor 


1.0 


0.909 


0.826 


0.751 


0.683 


0.621 


0.564 


0.513 


Present Value 


$ 157,660 


$ 72,943 


$66,312 


$ 60,284 


$ 54,803 


$49,821 


$45,292 


$41,174 


Total PV 


$ 548,288 



Table 4. Present Value of Alternative 3 Costs 
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b. Benefits 



It has been assumed that all three alternatives will accomplish the 
mandated requirements of EME. The tangible benefits of each alternative are achieved 
by performing the same job at a lower net present cost than the other competing 
alternatives. A number of intangible benefits can be identified that are independent of the 
direct requirement. The value of these “intangibles” should be weighed by the system 
owner in addition to the strict bottom line cost. 

Both the single-user and multi-user systems offer increased manageability 
of data to the EME program staff because electronic files are easier to maintain, 
duplicate, and transfer than paper ones. Further, both systems offer an adaptable query 
and reporting capability which is not available in a manual system. There is intangible 
value in the speed of information processing and reduced wait time for the customer 
provided by these options. Finally, through automation, the EME program would realize 
increased data accuracy and ease of verification by using exception reports, traditional 
automated database functions, and by involving the officer more closely with their 
educational record (Figure 3). 



Information is accurate and accessible so 
owner incorporates it into decisionmaking 




EMETRAK infor- 
mation is more 
accurate 






Officers take ownership of their 
own data and actively participate 



Figure 3. Data Verification Process 
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The multi-user system offers additional intangible benefits over each of 
the other alternatives. The first of these benefits is the increased speed of response to 
customer updates, queries, and reports. By distributing the application and moving many 
of the system functions out of a central program office and closer to the customer, 
response time for information should dramatically decrease. Moreover, the availability of 
program information should not be limited to the business hours of the EME program 
office. With an on-line system such as that envisioned in Alternative 3, customers could 
simultaneously access the system 24 hours a day. Finally, a distributed multi-user system 
would also allow the data entry function to be moved closer to the input source at the 
MTF, thereby increasing data accuracy and reducing data entry delays. 



c. Cost-Benefit Analysis Conclusions 

The objective of the economic feasibility analysis was to examine the 
costs and benefits associated with the development of an information system. Three 
alternatives were examined and the present value costs of satisfying a given set of 
requirements are summarized in Table 5. 



Alternative 


System 


P V Cost 


1 


Manual 


$666,400 


2 


Single-user DBMS 


$398,242 


3 


Multi-user DBMS with distributed I/O 


$548,288 



Table 5. Present Value Cost Summary 



Alternative 2 is the least cost solution and it should be selected if tangible 
benefits are the major evaluation factor and if the project continues to match the 
assumptions stated in the cost-benefit analysis. Alternative 3 provides a number of 
intangible benefits which could be benefit the EME program. If the value of these 
intangibles to the EME program is greater than $150,046 (or the difference between 
Alternatives 2 and 3), then Alternative 3 should be selected. 
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Alternative 3 costs appear to exhibit economies of scale if the scope of the 
EME program expands significantly. This does not appear to be the case for Alternatives 
1 and 2, as their marginal costs will quickly begin to rise if the program continues to 
expand. Therefore, if the EME Program expands its officer base or is adopted as a DOD- 
wide program, then Alternative 3 should be seriously considered. If this situation 
develops and a phased implementation strategy is adopted, Alternative 2 would provide 
an excellent migration path to the multi-user distributed application. 



4. Technical Feasibility 

A single user application developed using a fourth generation language (4GL), 
which closely involves the end-users, and which employs rapid prototyping techniques 
does not pose significant technical risk. Technical feasibility, however, is clearly the 
focus risk factor in Phase II of the project. Remote multi-user database operations have 
been performed within the MANs and LANs of Navy Medicine for several years but, to 
date, they have possessed only crude user and graphical interfaces. Operating a client- 
server database management system across a WAN using the Internet is still a serious 
technical challenge. 

Although the Phase I system will not use telecommunications links between sites 
to access system data, the infrastructure known as Medical Open Architecture (MED-OA) 
is in place for future development of an on-line system. The chief benefit of the MED- 
OA initiative, which was begun several years ago, was the standardization of hardware, 
network architectures, and applications throughout Navy Medicine. MED-OA provided 
the means through which all Navy MTFs could have connectivity via electronic mail and 
the Internet. The MED-OA infrastructure now primarily supports the functionality of the 
Composite Health Care System (CHCS), which is the DOD-wide patient scheduling and 
appointment system, but it can serve as a medium for a number of other applications. 

The on-line system envisioned in Phase II would not require heavy transaction 
processing. Data throughput requirements, therefore, are anticipated to be low and a 
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major technical hurdle could be overcome by using MED-OA and the NMDN backbone 
for data communications. The NMDN WAN connects regional MANs through relatively 
small capacity 56 kilobits per second (kbps) digital connections (Figure 4). Internal 
connectivity between the hospitals and clinics within a metropolitan area is more robust 
with T-l connections and the availability of DS-1 data rates (1.54 megabits per second - 
Mbps). Some MANs even have Fiber Distributed Data Interface (FDDI) connections 
with 100 Mbps data rates available between several of the medical facilities within that 
regional area. 

Detailed MAN topologies were provided by the Navy Medical Information 
Management Center (NMIMC) and are included in Appendix C. The individual MTF 
LAN architectures were standardized under the MED-OA initiative and are Ethernet 
networks with Carrier Sense Multiple Access/ Collision Detection (CSMA/CD) access 
methods and 10 Base T unshielded twisted pair (UTP) wiring which support 10 Mbps 




Figure 4. Navy Medical Department Network 
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data rates. The MTF LANs are connected to regional MAN hubs and DISN through 
Cisco® routers (Figure 5). 



802.3 ETHERNET ARCHITECTURE 



CSMA/CD 




Figure 5. Navy MTF Local Area Network Topology 



The primary concern with using the existing NMDN backbone to support 
EMETRAK is the limited bandwidth provided by the DISN 56 kbps connections which 
provide connectivity between the MANs. These links must support a number of other 
medical applications and will inevitably become bandwidth limited as WAN traffic 
increases in the future. Technically feasible alternatives to using the current NMDN 
include use of dedicated Integrated Services Digital Network (ISDN) connections to 
some EME customer sites or dial up access via modem. 
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5. 



Schedule Feasibility 



Implementation of the EME program curriculum begins within 60 days of project 
commencement, therefore the use rapid prototyping techniques will ensure that a Phase I 
prototype application achieves an initial operational capability before the end of FY-95 as 
specified by the system owner. The long-term requirement for Phase II is not as schedule 
constrained and will allow a more detailed examination of the critical issues such as 
bandwidth and connectivity requirements, security concerns, and interoperability with 
other DOD and Navy systems. Development of a Phase II system can be achieved by the 
end of the third quarter of FY-96. This allows two months for system design, four months 
for system development, two months for testing, and one month for distribution and 
installation. 



G. LESSONS LEARNED DURING THE SYSTEMS ANALYSIS PHASE 

1. Requirements Review 

Systems analysts and programmers are fearful of changing requirements. Change, 
however, is the only constant in the systems development process and IT professionals 
continue to deal with changing requirements in every project. Customers frequently 
reassess their requirements as a result of the questions and issues raised by the analyst 
during the detailed investigation of the business processes. Usually an agreement 
between the system owner and systems analyst is reached before the requirement is 
finalized and a specification is developed. If agreement is not reached then requirements 
are likely to change during the course of systems development. 

One such issue arises in the Systems Analysis phase of the EMETRAK project. 
The system owner desires a statistical reporting capability for competencies attained by 
officers enrolled in the program. This presents a problem for the analyst because the 
curriculum is still under development and the EME Program Management Group is 
having difficulty determining which courses are required to complete a specific 
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competency at this stage of curriculum development. In the absence of defined criteria 
for competency definition, the measurement of completed competencies and statistical 
analysis of the data are impossible. The competency issue is a difficult one and remains 
unresolved at the conclusion of the Systems Analysis phase. Although a problem exists 
with the requirement for statistical reporting at this stage, delays in the development of a 
prototype are not anticipated. The completed competency issue is an example of a 
business rule problem which should be addressed by EME Program Management Group 
if the requirement for statistical reporting is to be incorporated into the production version 
of EMETRAK. 

The lesson learned from this example is that it is the analyst’s responsibility to 
determine which issues are business problems and which can be solved through the 
implementation of technology. The analyst must recognize the distinction between 
business and technology issues and communicate those to the system owner. If the owner 
and analyst frequently review the requirements at this phase of the SDLC, then problem 
areas can be identified and changes to system requirements can be incorporated with little 
expense or delay. Changes to the system requirements which occur in later phases of a 
project are more costly to implement and can delay fielding of the production system. 



2. Life Cycle versus Bottom-Line Costs 

A considerable body of literature exists which addresses the subject of identifying 
total life cycle costs in a cost-benefit analysis for IT systems development. While this 
method captures the true cost of a system over its life cycle, it is not always understood or 
even used as a practical estimate for DOD program managers who deal in real dollars and 
whose programs are judged by their price tags in the current year. While the cost-benefit 
analysis for this project looks at the total projected life cycle costs discounted over seven 
years, the program manager is more concerned with the straight bottom line costs of the 
system hardware and software as they relate to the annual program budget. 
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3 . 



System Owner-Systems Analyst Relationship 



A strong relationship is required between the system owner and the systems 
analyst in order to complete a successful development effort. The quality of that 
relationship can not be overemphasized; it must be based on mutual trust and credibility. 

The owner relies on the analyst to provide a technical solution which solves a 
particular problem and, often times, must meet strict operational, economic, and schedule 
constraints. This situation requires that the system owner trust the analyst because every 
facet of the owner’s business environment and organizational processes will be exposed 
to investigation and analysis during the development of the IT system. The analyst, in 
turn, trusts the owner to establish an atmosphere where free access to the organization’s 
people and resources are possible in order to complete a thorough study of the 
environment. 

Establishing credibility with the system owner at an early stage of the 
development process is another important consideration. Political support may be 
required when dealing with difficult internal organizational issues or policies and having 
credibility with the system owner makes the job of getting political support a little easier. 
This type of support may be particularly crucial when process improvement is required 
within the organization rather than attempting to automate a flawed business process. 

The rapport between the EME Program Management Group and system analysts 
during the Systems Analysis phase of this project has been outstanding. The system 
owner’s support and interest enabled a thorough study of the business environment and 
system requirements, allowing the EMETRAK project to move forward without delay. 
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III. SYSTEMS DEFINITION PHASE 



A. METHOD 

The purpose of the Systems Definition phase is to define the business rules and 
requirements of the proposed system without consideration of a specific technology or 
implementation. This is accomplished by translating the user-identified capabilities into 
implementation-independent models that describe desired system functionality. 
Implementation-independent models reduce the risk that functional requirements will be 
missed during systems design because of preoccupation with technical details. [Ref. 5, p. 
305] Two types of conceptual modeling techniques are used to describe the proposed 
system: process and data models. 



B. THE CURRENT ENVIRONMENT 

Administration of the EME program is characterized by manually intensive 
processes. Scheduling, coordination, and confirmation of classes is conducted through 
postal mail, electronic mail, telephone conversations, or via facsimile transmissions. 
Class attendance is recorded on hand-written rosters circulated by the instructor at the 
course delivery sites. Instructors deliver class rosters and course evaluations to the EME 
program office for processing by the administrative staff upon returning from a teaching 
assignment. 

The EME administrative staff have access to and use office automation 
applications for routine word processing, presentation graphics, and limited spread sheet 
functions. Course completion letters and certificates are generated by word processing 
application several days after class rosters are delivered to the program office. Once 
course completion letters and certificates have been processed they are mailed to an 
officer’s command. Verification of officer data is accomplished through feedback from 
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the individual officer via electronic mail, telephone, or facsimile. Results from course 
evaluations are collated and entered into a spread sheet application for further analysis by 
the EME program management group. Paper copies of all class rosters, completion 
letters, certificates, and course evaluations are stored at the NPS program office. 

Program data is not recorded in a single application or stored in a central location, 
therefore, information is not easily retrievable. This situation adversely impacts the 
reporting capability of the system. Reports are ad hoc and manually generated from data 
appearing on class rosters, spread sheet print-outs, or internal memoranda which is very 
time consuming. 

The primary challenges in the current system are timely data collection, data 
verification, and information retrieval. The scope in the proposed system, therefore, must 
incorporate the stakeholders, namely the officers themselves, in the information process 
at the MTF level. It must also be capable of supplying the EME staff at NPS, the EME 
program manager at NSHS, BUMED, and the Medical Department Corps Chiefs with 
information to successfully manage the EME program. Finally, the new system must 
include BUPERS in its scope for importing basic officer information to overcome current 
data accuracy and data verification problems. 



C. THE PROCESS MODEL 

Process modeling is a technique for organizing and documenting a system’s 
business processes, inputs, outputs, and data stores. The process model consists of 
decomposition and data flow diagrams. [Ref. 5, p. 350] 



1. Decomposition Diagrams 

Decomposition diagrams graphically portray the user requirements in terms of 
system functions and processes. They serve as a blue print for the structure of the system 
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from which data flows are modeled. The EMETRAK decomposition diagrams have three 
levels (zero, one, and two) that identify key system processes. 

a. Level Zero 

The level zero or overview decomposition diagram (Figure 6) depicts three 
subsystems: data maintenance (process PI), analysis (process P2), and reports (process 
P3). 




Figure 6. Level Zero Decomposition Diagram 



b. Level One 

Level one diagrams decompose each subsystem into subordinate 
processes. These processes correspond to the information system functions specified in 
the previous chapter. Subordinate processes which have pound signs (#) next to the 
process number indicate the lowest level logical function. 

Processes P 1.1 through P 1.5 (Figure 7) conform to the functions required 

to collect, maintain, and manage data identified by the system owner during the analysis 

« 

phase. 
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Figure 7. Level One Process One Decomposition Diagram 



Processes P 2.1# through P 2.3# (Figure 8) reflect the three general types 
of queries identified in the information system functions section of the previous chapter: 
structured, interactive, and statistical. 




Figure 8. Level One Process Two Decomposition Diagram 



Processes P 3.1# through P 3.3# (Figure 9) identify the general categories 
of reports requested by the program manager. Reports are closely related to system 
queries, however, they are modeled as distinctly different logical processes during 
systems definition. 
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Figure 9. Level One Process Three Decomposition Diagram 



c. Level Two 

The level two diagrams (Figure 10) depict the lowest level logical 
functions of the proposed system. The Update Officer Information process (P 1.1) is 
decomposed into the add officer, modify officer information, delete officer, and change 
location sub-processes (P 1.1.1# through P 1.1.4#). Update Course Information (P 1.2) 
decomposes into the add course, modify course information, and assign course to 
competency sub-processes (P 1.2.1# through P 1.2.3#). Update Command Information (P 
1.3) is comprised of the add command, modify command information, and delete 
command sub-processes (P 1.3.1# through P 1.3.3#). Generate Class Information (P 1.4) 
contains the add class and modify class information sub-processes (P 1.4.1# through 
1 .4.2#). The last level two process, Import/Export Information (P 1 .5), consists of the 
create backup, import BUPERS data, database file import, and database file export sub- 
processes (P 1.5.1# through 1.5.4#). 
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Figure 10. Level Two Decomposition Diagrams 



2. Data Flow Diagrams 

Data flow diagrams (DFD) model the flow of data through a system’s essential 
processes. They combine information from both the context and decomposition diagrams 
into a series of charts showing entity, data, and process interactions. Recall that a context 
diagram identifies which external entities interact with the system and decomposition 
diagrams identify the essential system processes. In a DFD, data is input by external 
entities, transformed by system processes, and output to other external entities. The 
convention followed is the Gane and Sarson symbol set which uses processes, data flows, 
internal or external entities, and data stores [Ref. 5, pp. 350-352]. Further, the explosion 
technique is used to diagram data flows wherein essential processes illustrated in the 
overview diagram (Figure 11) explode to greater levels of detail in subsequent charts 
(Appendix D). 
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a. Overview DFD 

The overview DFD contains all of the entities depicted in the EMETRAK 
context diagram and shows how they logically interact with the three major system 
processes: maintain data, conduct analysis, and generate reports. There is only one data 
store at the overview level, but it is divided into smaller data stores in lower level DFDs. 

Process P 1 receives data input from the EME staff at NPS (EME), the 
program manager (NSHS), BUPERS, and the customer sites (MTFs). Process P 1 then 
transforms (i.e. adds, modifies, or deletes) the data and sends the output, “updated 
program information”, to temporary storage in DB.EMETRAK. 

Processes P 2 and P 3 perform similar operations on EME data and 
produce various queries or reports for the requesting external entities. 




Structured and Interactive Reports 



Figure 1 1 . Overview Data Flow Diagram 



37 



b. 



Level One DFDs 



Level One DFDs detail the major processes identified in the 
decomposition diagram and the overview DFD. 

In the Level one-Process one chart (Appendix D, p. 107), EME provides 
officer and course data inputs, NSHS provides command and billet information, MTFs 
submit class rosters, and BUPERS provides the master Officer List. Each sub-process (P 
1.1 through 1.5) transforms the data flows into “updated information” for the 
DB.EMETRAK data store. The MTFs provide feedback to the system in the form of 
“verified officer information” to the Update Officer Information process (P 1.1). The 
only output at this level is the “file export” data flow to the program manager (NSHS). 

Level one-Process two (Appendix D, p. 108) shows “program data” 
flowing from the data store (DB.EMETRAK) and being transformed into either a 
“structured query”, “interactive query”, or “program statistics”. The query capability is 
available to all external entities, however, statistics are only provided to EME and NSHS 
for program management purposes. 

Level one-Process three (Appendix D, p. 109) is very similar to the 
previous diagram but for structured, interactive, and statistical reporting. 



c. Level Two DFDs 

In level two, the process one functions are more closely examined and the 
DB.EMETRAK data store is divided into smaller logical data stores (Figure 12). 

Process 1.1 adds, modifies or deletes basic officer information in the 
system (Appendix D, p. 110). The external agencies that interact with the system are 
EME, NSHS, and the MTFs. EME or NSHS provide “officer information” to the Add 
Officer process (P 1.1.1#). The MTF provides “verified of officer information" and P 
1.1.1# transforms the two data flows into a “new officer entry” which is placed in the 
OFFICER data store (DS 1). In P 1.1.2#, EME or NSHS provide “additional officer 
information” which is used to modify existing data in DS 1. In P 1.1.3#, EME or NSHS 
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provide the “officer identification number” which is transformed into an “officer to 
delete” data flow. In the last process. Change Officer Location (P 1.1.4#), EME or NSHS 
provide a “new location” which is transformed into an officer’s “new officer location” in 
DS 1. 

Process 1.2 (Appendix D, p. Ill) adds or modifies course information in 
the database or assigns a course to an EME competency category. EME or NSHS 
provide “new course” or “additional course data” input. The Add Course and Modify 
Course Information processes (P 1.2.1# and P 1.2.2#) transform their respective data 
flows which update information in the COURSE data store (DS 2). EME or NSHS also 
provide “course and competency information” which is transformed into a “new 
competency classification” and is stored in the COMPETENCY data store (DS 5). 



DS 1 OFFICER 



DS 2 COURSE 



DB.EMETRAK 




DS 3 UIC 



DS 4 CLASS 



DS 5 COMPETENCY 



DS 6 BACKUP 



Figure 12. EMETRAK Data Decomposition Diagram 



Process 1.3 (Appendix D, p. 112) adds, modifies, and deletes command 
information of EME participants. NSHS provides input to the Add Command , Modify 
Command Information, and Delete Command processes (P 1.3.1#, P 1.3.2#, and P 
1.3.3#). Each process performs an operation on the data which updates the UIC data 
store (DS 3). 
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Process P 1.4 (Appendix D, p. 113) addresses adding classes and 
modifying class information. The Add Class process (P 1.4.1#) receives input from 
EME, the MTF and the COURSE data store (DS 2). EME provides “verified officer 
information” and the MTF provides the validation of a class occurrence by initiating the 
“class roster” input. The process also extracts the course number and course name from 
DS 2. All inputs are transformed into a new class occurrence for a specific officer in the 
CLASS data store (DS 4). Modify Class Information (P 1.4.2#) simply receives input 
from EME and modifies existing data in DS 4. 

Import/Export Information (P 1.5) defines the utility functions of the 
system (Appendix D, pp. 114-1 17). P 1.5.1# shows the system back up function, process 
P 1.5.2# illustrates the BUPERS officer master data file import, and processes P 1.5.3# 
and P 1.5.4# depict the file import/export functions between the EME office at NPS and 
the program manager. 



D. THE DATA MODEL 

A major goal in the early stages of database development is to build a data model 
that documents the entities to be represented in the database, to determine the 
characteristics of those entities, and to describe the relationships among them. A method 
known as semantic object modeling is used to study and document the entities, known as 
semantic objects, to be stored in the database. A semantic object is a representation of 
something identifiable in the user’s work environment or business process. It is a “named 
collection of attributes” that sufficiently describes a distinct identity [Ref. 9, pp. 79-81]. 
The “named collection of attributes” represents all of the characteristics that the users 
need to accomplish their tasks. The SALSA® software application is used to construct 
semantic object diagrams and, ultimately, a database schema. Semantic object diagrams 
summarize the structures of objects in a system and visually present them. 
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1 . 



Semantic Objects 



Five internal entities or objects in the EMETRAK system identified in the 
previous chapter are modeled: OFFICER, UIC, CLASS, COURSE, and COMPETENCY. 
A new object, COURSECOMP, is also modeled that describes an instance of an EME 
course assigned to a particular competency category. 

The OFFICER object (Figure 13) describes an officer enrolled in the EME 
program. The officer is uniquely identified by the SSN and has a group attribute called 
OfficerName. The OfftcerName group attribute consists of the LastName, FirstName, 
and Minitial simple attributes. Other simple attributes that describe the officer are Rank, 
BSC (billet sequence code), Designator, Subspecialty, JobTitle, and Email (address). The 
OFFICER object is related to the UIC and CLASS semantic objects. The integers to right 
of the object attributes are the attribute’s minimum and maximum cardinality. The 
minimum cardinality is the minimum number of instances of the attribute that must exist 
for the object to be valid. The maximum cardinality indicates the maximum number of 
instances that an attribute may have. In the OFFICER object, the officer is related to one 
and only one (1.1) command (UIC) and may be related to zero or many (O.N) instances of 
a CLASS. 

The UIC object is uniquely identified by the UICNumber attribute. It has the 
following additional attributes: UICName, Address, Phone, and HealthSvRegion. The 
UIC object may have from zero to many officers assigned as indicated by the cardinality 
of the OFFICER object contained within UIC. 

The CLASS object has a unique composite identifier consisting of the OFFICER 
ID ( Ssn ) and COURSE ID ( CourseNumber ). The CLASS object is an instance of an 
officer taking an EME course on a specific date. The CLASS attributes are ClassDate, 
Instructor , and CourseLocation. 
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Figure 13. OFFICER, UIC, and CLASS Semantic Objects 



The COURSE semantic object (Figure 14) describes an EME course offering. It 
consists of the CourselD, CourseName, Hours, CEUCredits, CourseDesc (description), 
and CourseSponsor attributes. A COURSE may be related to zero or many instances of 
CLASS but must belong to at least one competency category (COURSECOMP). 

The COURSECOMP object is identified by a composite identifier consisting of 
CourselD from the COURSE object and Competency from the COMPETENCYCAT 
object. The COURSECOMP object models an intersection relation between the two 
objects which will be helpful during database implementation to overcome certain data 
anomalies described in the next chapter. 

The COMPETENCYCAT object is uniquely described by the Competency 
attribute which is simply the EME competency category title. 
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Figure 14. COURSE, COURSECOMP, and COMPETENCYCAT Semantic Objects 
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E. 



LESSONS LEARNED DURING THE SYSTEMS DEFINITION PHASE 



The modeling techniques used in this phase facilitated a comprehensive study of 
the business processes employed by both the EME program management group and 
administrative staff. The capabilities desired by the system owner and users drove the 
detailed nature of the study. Translating those desired capabilities into proposed system 
functions required a thorough understanding of the day-to-day administrative procedures 
as well as the overall EME program management strategy and objectives. The techniques 
discussed in this chapter helped achieve that goal. 

Two key decisions occurred during the Systems Definition phase that impact the 
future development of the EMETRAK system. First, the program manager at NSHS 
expanded the scope of EMETRAK concomitant with the two-phased development 
strategy articulated in the previous chapter. The concept for the development of a multi- 
user database application, accessible from every major Navy MTF, was approved and 
funded as part of the FY-96 program budget. This decision reinforced the notion of using 
a 4GL rapid application development tool to build a working prototype. 

A working prototype would provide the EME staff with an immediate data 
collection and reporting capability while a final production system is developed. 
Moreover, the prototype system could serve as an adjunct to the written requirements 
specification to more accurately define multi-user requirements in terms of data 
structures, user interface, and system outputs. 

The second decision was approval of the concept to partner with the Defense 
Manpower Data Center (DMDC) to develop the multi-user system (Phase II). The terms 
of the partnership are not final, but they involve developing the requirements 
specification as part of this study and turning those products over to DMDC programmers 
for coding and testing. Under this plan, the EME Program would reimburse DMDC for 
the level of effort and materials required for system development. While the exact level 
of effort required is undetermined at this stage, a DOD partnership should result in 
significantly lower development costs compared to those predicted in the cost-benefit 
analysis. 
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IV. SYSTEMS DESIGN PHASE 



Database and application design are the major themes of this chapter. The 
relational model is the foundation for database design and applies to both the single-user 
and multi-user versions of EMETRAK. Application design, however, focuses on the 
design of specific database components and the user interface. These components are 
peculiar, in some cases, to Microsoft Access® therefore application design issues as 
discussed in this chapter are restricted to the single-user system (Phase I). Multi-user 
application design issues are addressed in a subsequent chapter. 



A. DATABASE DESIGN 

Transformation of the semantic object model into a relational database design is a 
two step process. First, the semantic objects are converted into a relational model. The 
relational model is important because it expresses a database management system 
(DBMS) independent design. The relational model is comprised of relations which are 
two-dimensional tables storing data pertinent to the original semantic themes. 
Representing semantic objects as relations facilitates normalization. Normalization is a 
fundamental concept in relational database design and is the process of converting a 
relation that has certain problems into two or more relations that do not have these 
problems. [Ref. 9, p. 125] The problems alluded to are known as modification anomalies 
and refer to operations requiring several steps to either insert or delete data as opposed to 
one atomic operation that updates data in multiple related tables at once. 

The second step in the transformation process is constructing a database schema. 
The database schema is a set of rules that defines the relational database structure, its 
domains, tables, and relationships. A database schema can be thought of as data that 
describes the database. Most modem database modeling tools, such as SALSA®, 
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automatically generate a database schema which is imported into a specific DBMS as a 
template for the application’s database tables. 



1. Relational Model 

Relations consist of rows, also known as tuples, and columns. The intersection of 
the rows and columns are called cells. In order to qualify as a relation, a table must 
conform to some basic rules which govern the content of its rows, columns, and cells 
[Ref. 9, p. 126]: 

• Each cell in a table must be single-valued (no repeating groups or arrays are 
allowed) 

• Each column in a table must have a unique name 

• All entries in a column must be of the same kind (or theme) 

• All rows in a table are unique (no two are identical) 

• The order of the rows or columns in a table is insignificant 

The unique names of the columns in a relation are called attributes. These 
attributes correspond to the same attribute names represented in the semantic object 
model in Chapter III. Unique rows in a relation are identified by an attribute called the 
primary key. Notice that no two rows in a relational table can have the same primary key 
and duplicate data as this violates the rules of a relation. The ID attributes from the 
semantic object model become primary keys in the relational model and eventually in the 
database tables. 

One of the reasons for selecting the semantic object modeling technique was that 
relationships between semantic objects, and ultimately relations, are automatically 
generated by the software modeling tool. The only manual task required of the developer 
is to identify many to many (M:N) relationships between objects and divide these into 
separate one to many (1:N) relations to comply with standard normalization rules. The 
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other advantage of using semantic object modeling is that normalization problems 
associated with relational database design are less likely than with other methods such as 
entity-relationship models because objects already conform to semantic themes. This is 
the essence of normalization - every normalized relation has a single theme. 

Relations are further classified by the types of modification anomalies to which 
they are vulnerable. Without explaining the details of each normal form, suffice it to say 
that the goal for the EMETRAK relational model is third normal form which eliminates 
most of the modification anomalies. A relation in third normal form has the following 
characteristics: 

• A table containing data must meet the definition of a relation 

• All of the non-key attributes in a relation depend on all of the primary key 

• None of the attributes of relations have transitive dependencies 

The EMETRAK relational model consists of six relations and their corresponding 
relationships (Figure 15). The underlined attributes represent primary keys in a relation 
and italicized attributes represent foreign keys. Foreign keys are the linking mechanism 
to a related table. Notice that foreign keys in one relation are the primary key in a linked 
relation. Lastly, the cardinalities from semantic object attributes transform into 
relationships in the relational model. 



a. UIC Relation 

An instance or single occurrence in the UIC relation is uniquely identified 
by its UIC Number which is the primary key. A UIC may have from zero to many 
officers assigned but an officer must be related (assigned) to a specific UIC. The UIC 
and OFFICER relations are linked through a foreign key (UIC) appearing as an attribute 
in the OFFICER relation. 
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b. 



OFFICER Relation 



An officer is identified by a unique SSN and may have completed from 
zero to many classes. However, a CLASS occurrence must be related to an OFFICER 
instance to exist. 



c. CLASS Relation 

The CLASS relation is an occurrence of an officer taking an EME course. 
The primary key in the CLASS relation is a composite key consisting of foreign keys 
from both the OFFICER and COURSE relations. These foreign keys link the two 
relations to CLASS. A CLASS must be related to an occurrence of COURSE to exist. 



d. COURSE Relation 

A COURSE is identified by a unique course number - the CourselD 
attribute. A COURSE may be related to zero or many occurrences of CLASS. A 
COURSE may also belong to several EME competency categories. 



e. COMPETENCYCAT Relation 

The COMPETENCYCAT relation represents the various competency 
categories addressed by the EME program. An instance in the COMPETENCYCAT 
relation is identified by the competency title specified in the program literature. A 
competency category has many associated courses and an EME course may belong to 
several competency categories. This situation represents a many to many (M:N) 
relationship which is susceptible to a variety of modification anomalies during database 
implementation. Normalization rules require that many to many (M:N) relations be 
divided into two or more one to one (1:1) relations to reduce modification anomalies. 
The solution is constructing the intersection relation COMPCOURSE. 
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f. COMPCOURSE Relation 

The COMPCOURSE intersection relation stores very little data; it is 
simply a listing of EME competencies and associated course numbers. The composite 
primary key for the COMPCOURSE relation consists of foreign keys from the 
COMPETENCYCAT and COURSE relations. 

The many to many relationship between the course and competency 
category relations only became apparent during the development of the relational model. 
The semantic object model had to be later modified to reflect the development of the new 
intersection relation. 



2. Database Schema and Table Generation 

SALSA® generates the database schema in an exportable format. The schema is 
then imported into the DBMS application and the basic structure for database tables is 
developed from the semantic object domain, attribute, and relationship code. Although 
somewhat automatic, the table generation process still requires the developer to perform 
minor modifications on table relationships, attribute names, and field lengths. Once the 
tables are generated in the DBMS application, developers can begin to focus on 
application and user interface design. 
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Competency COMPETENCYCAT 



B. APPLICATION DESIGN 



1. General Considerations 

When designing the EMETRAK prototype application, several factors and 
considerations were taken into account. First, the application was designed to fulfill the 
system owner’s requirements and support the EME program objectives. Second, since 
end-users were not likely to use the application every day, it had to have an intuitive and 
user-friendly interface. Finally, the prototype had to provide clear and complete 
specifications to the programmers who would later be developing the multi-user system. 
Consequently, application design required close coordination between the developers, the 
system owner and several prospective end-users. The system owner was involved in the 
approval of form, query, and report design and approved each component for logic and 
correctness. Because the EMETRAK Phase I application was a prototype design, some 
sacrifices in efficiency, security, and error handling were accepted in favor of rapid 
application development. 



2. Principles of Interface Design 

The Microsoft Windows® basic user interface design principles described by the 
event driven programming model were adhered to during application design. [Ref. 1 0, p. 
34-35] 

• User in Control - In the event driven programming model, the application 
should be the servant not the master. The user controls the actions of the 
application not the reverse. 

• Directness - The application should be straight-forward in its design. Users 
do not want to deal with files, bytes, etc. The user should be able to select an 
object (form, input box, button, etc.) and perform an action on that object. 
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• Consistency - End-users want to know what to expect in an application. The 
sooner a user is comfortable with the application, the sooner they stop 
working with a program and start using a tool. 

• Clarity - The design should have intuitive entry forms and message boxes for 
data exchange. The entities represented in the tables should have one theme 
and make sense. 

• Aesthetics - Color and layout are important. Users want crisp eye-pleasing 
displays not garish designs. 

• Feedback - Providing immediate feedback to end-users when an event takes a 
substantial amount of time is an important design concept. This feature lets 
the user know they have temporarily relinquished control of the application 
while background processing is being accomplished. 

• Forgiveness - The application should allow the user to recover from mistakes 
easily and without crashing. Access 2.0 provides a built-in multi-level undo 
function which was used in the EMETRAK design along with warnings and 
dialog message boxes. 

a. EMETRAK Design 

EMETRAK was designed with a branching architecture rather than the 
typical hierarchical menu structure found in many database applications. The application 
opens directly to a main input form titled Officer Record from which the user can 
immediately view officer information or navigate to other application features. Buttons 
that “branch” or link to other application functions such as table views, reports, and 
utilities are all easily accessible on the main input form. 
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3. 



Input Forms and Menus 



a. Officer Record Form (Figure 16) 

Most of the information relevant to an officer enrolled in the EME 
program appears on the Officer Record form. Basic information from the officer data file 
appears in text boxes in the upper half of the form and a sub-form showing officer 
transcript information appears on the lower half of the form. By selecting an object- 
action button on the Officer Record form, the user can view information about an 
officer’s command, see how many program hours an officer has completed sub-divided 
by competency category, or add information on a completed course. Buttons on the 
Officer Record form also allow the user to view system tables, access the reports menu, 
and edit officer data. 



b. Command Info Form (Figure 17) 

The Command Info form opens when the Display UIC button is selected. 
The form displays the officer’s unit title, address, telephone number, and HSR. 
Command information may be updated directly on the Command Info form. 



c. Add New Class Form (Figure 18) 

The Add New Class form opens on top of the Officer Record form when 
the appropriate button is selected. The Add New Class form allows the user to enter 
completed course information on any officer in the database not just the officer record 
underlying the form. Upon entering the officer SSN in a text box, the officer’s name 
automatically appears on the form. This provides the user with instant feedback and 
verification of an officer’s name and SSN. An officer must first exist in the database 
before entering class information. 
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d. 



Hours by Competency Form (Figure 19) 



Selecting the Competencies button on the Officer Record form opens the 
Hours by Competency form. This form shows the number of EME hours completed by 
the officer grouped by competency category. The system owner agreed to a design that 
shows hours completed vice completed competency categories because of the unresolved 
competency issue addressed in the earlier chapters. 



e. View Tables Menu (Figure 20) 

Selecting the Tables button sends the user to the View Tables menu. The 
View Tables menu provides the user with the ability to view the COURSE, UIC, or 
COMPETENCYCAT tables. Users may edit data stored in these tables in the prototype 
application. 

f. Report Menu (Figure 21) 

The Reports button on the Officer Record form opens the Report Menu. 
The Report Menu provides the user with a selection of ten pre-formatted reports that can 
be viewed in a tabular query form, a screen report format, or printed in hard paper copy. 



4. Utility Functions 

Six buttons on the right side of the Officer Record form provide basic record and 
file utility functions. The user may add a new officer record, save modifications to the 
current record, find a specific entry in a selected field, toggle to the next or previous 
record, or exit the application. 
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c. 



LESSONS LEARNED DURING THE SYSTEMS DESIGN PHASE 



The prototyping approach was used to validate the design of the user interface, 
screens and reports. It helped clarify system requirements and reduce uncertainty with 
the system owner during development. The greatest benefit proved to be in soliciting 
input from the system owner and users who were not exactly sure about what they wanted 
until they saw it on a computer screen. Moreover, rapid prototyping facilitated 
constructive user comment and continuous feedback which reduced errors in application 
design. 
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Figure 16. Officer Record Form 



55 










Figure 17. Command Info Form 




Figure 18. Add New Class Form 
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V. EMETRAK PROTOTYPE IMPLEMENTATION 



A. PROTOTYPE APPLICATION STRUCTURE 

Relational databases apply the principles of the relational data model in which 
data is organized into logical mathematical sets in a tabular structure. This allows data to 
be stored more efficiently and with less overhead than older file management or 
hierarchical systems. Efficiency is measured in terms of memory requirements and 
access speed. 

While efficiency is important, database quality is usually the primary criteria for 
selecting for a particular database model. The quality of a database is largely determined 
by the accuracy of the data it stores. Therefore, a primary goal of the relational database 
model is to preserve data integrity. Integrity is preserved by preventing access to data 
from outside of the DBMS that created it. In a relational database management system 
(RDBMS), data can only be accessed through queries handled by the DBMS engine 
itself. Thus in a relational system, data is stored in linked tables, it is accessed only 
through DBMS queries, and it is presented in database forms and reports. [Ref. 1 1, p. 16] 

Microsoft Access 2.0® is a true RDBMS application. The database engine 
provides strong data integrity by limiting access to data and by enforcing robust 
referential integrity rules. It was selected for development of the EMETRAK prototype 
system due to its intuitive object-oriented design features, simple query facility, and 
powerful database engine. Access uses tables, queries, forms, reports, macros, and 
modules in its DBMS implementation. 
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1 . 



Tables 



A relational database is designed to manage information stored in multiple tables. 
Tables contain information from a single object class or theme organized into rows and 
columns. Each row represents an individual record and the columns, called fields, are 
describing characteristics of that record. Tables are created in Microsoft Access in two 
ways. A database schema or external DBMS table is imported and converted into an 
Access table or a new table is created from within the application itself. 

The prototype system consists of eight tables that were either created from the 
imported database schema or developed within the actual application. The EMETRAK 
table structures are described in the prototype database dictionary (Appendix E). 



2. Queries 

A query is a method of accessing the database by asking the DBMS a question or 
by sorting, grouping, or updating database information. These functions are performed 
by a sub-language known as Structured Query Language (SQL). SQL was explicitly 
designed to access DBMSs based on the relational model [Ref. 11, p. 27]. Microsoft 
Access uses its own proprietary version of SQL based on the American National 
Standards Institute version 89 (ANSI-89 SQL) standard to access data. Access also 
provides a visual interface to SQL known as query-by-example (QBE) which greatly 
simplifies writing database queries. Twenty-four queries were written for the prototype 
system and the significant ones are described in detail in Appendix F. 



3. Forms 

Database forms are a means of inputting data and presenting DBMS information 
on the computer screen. Database forms usually emulate paper forms found in an 
existing system and present the same type of information in a “paperless” format. Forms 
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are usually based upon system queries written to actually present or manipulate database 
information. Prototype system forms were described in section B of the previous chapter. 



4. Reports 

A report is either a paper or on-screen presentation of information. Access 2.0 has 
a flexible report generation capability that allows the development of reports which 
closely replicate those used in an existing system. 

Eleven reports were developed for the prototype system. The only existing 
system report which was replicated was the course completion letter. All other reports 
were developed based upon new input from the system owner. Each report was designed 
with a similar “look and feel” to present a standardized format. Prototype system reports 
are provided in Appendix G. 



5. Macros 

Access provides a powerful capability to manipulate database objects and 
automate repetitive tasks through the use of macros. A macro is a small menu-driven 
sub-routine that provides its functionality without requiring complex coding on the part 
of the developer. Macros were used extensively in the prototype system to quickly 
develop menus and reports. 



6. Modules 

A module is a container within Access that stores Access Basic procedures. 
Access Basic is a programming language that allows the developer to customize database 
objects by defining methods, properties, and actions through code. The EMETRAK 
prototype system only has one module. The functions stored in that module are described 
in Appendix H. 
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B. 



REFINING THE PROTOTYPE APPLICATION 



Once the basic structure of a prototype database is completed and populated with 
test data, the developer integrates the various parts into a working application before 
beginning dedicated system testing. Integration and refinement include such things as 
verifying table relationships, standardizing form layouts, developing customized menus, 
providing a back up capability, and establishing user permissions or other security 
features. 

The prototype application was closely reviewed for accuracy of table 
relationships, keys, and referential integrity rules. Once the mechanics of the tabular 
structure was verified, the cosmetics of the user interface layout and menu structure were 
addressed. The color scheme and location of utility buttons on each form was adjusted to 
provide consistency and clarity. Further, a customized and simplified drop-down menu 
bar was added to enhance user efficiency. To enable an adequate back up facility, the 
prototype system was programmed to automatically copy database files to floppy disks 
using a DOS-based batch file procedure upon exiting the application. Finally, the Access 
security facility was invoked to enable user log on and password protection. User access 
was restricted to data entry, viewing, and printing. The user’s ability to modify the 
database design or directly access table structures and other security functions was 
disabled. 



C. OTHER IMPLEMENTATION ISSUES 
1. System Testing 

Testing is an important activity of the Systems Implementation phase because 
translation of user requirements into a working system is very complex and error prone. 
A top-down program development strategy was used for the prototype system to provide 
a structured approach to both system coding and testing. With the top-down approach, 
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the developer starts with a high level description and adds system components in a 
hierarchical fashion. The developer programs in increasing levels of detail until the 
specified functionality is achieved. Moreover, each module is tested along the way for 
interoperability with its parent or other related module. The advantage of this approach is 
that integration of the components is tested as the application is being developed resulting 
in smoother systems integration. [Ref. 3, pp. 312-313] 

Top-down testing involved both systems integration and unit testing of individual 
modules. In the prototype application, the highest logical level module was tested first 
and then each related module was independently tested using up to 250 records of test 
data. As problems were identified, the logic of the module was corrected until the desired 
functionality was attained. Each module in the logical structure of the prototype system 
was unit tested and no major problems were noted at the completion of systems 
integration testing. 

Once system testing was completed, the prototype application was made available 
to the EME program management group for final verification and validation. Each 
application function was demonstrated to the group and compared against the system 
owner’s stated requirements. System outputs were closely scrutinized by the system 
owner and the program manager at NSHS before final approval for installation was given. 



2. Training 

a. User’s Guide 

A system user’s guide was developed for the prototype application 
(Appendix I). The usability of the guide was then tested on a randomly selected end-user 
who was not familiar with either the prototype application or the contents of the user’s 
guide. The end-user was instructed to treat the guide as a tutorial for the prototype 
application. The session was closely monitored and suggestions from the end-user were 
included in the final version of the guide before distribution. 
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application. The session was closely monitored and suggestions from the end-user were 
included in the final version of the guide before distribution. 

b. Formal Training 

Two training sessions were conducted for approximately eight end-users 
before system installation. The training sessions encompassed a review of the user’s 
guide, an application demonstration, and hands-on experience with the prototype. 
Although formal training was deemed effective by the administrative staff, continuous 
technical support is anticipated in the months ahead until the multi-user system is fielded. 



3. Installation 

The prototype application is installed on a networked 486/66 DX2 PC with a 420 
megabyte hard drive, 16 megabytes of random access memory, and a network printing 
option installed. The PC uses Windows 3.11 and the Banyan network operating system. 
The prototype application runs within the Microsoft Access 2.0 DBMS not as a stand- 
alone program. 

During the installation, the data files were separated from the application and 
moved to another directory to reduce the possibility of data corruption due to program 
failure. Consequently, the DBMS tables are attached through address pointers rather than 
actually residing in the prototype application. 

A problem was encountered with activating the network printing option in the 
prototype application. After consulting with the network administrator, the problem was 
resolved at the network vice application level and printing was enabled. The final step in 
installation was activating system security and encrypting the database. 
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D. 



POST-IMPLEMENTATION EVALUATION 



Evaluation is an important tool in the SDLC to assess the success of a system and 
recommend improvements for subsequent versions or follow-on applications. Two 
methods will be used to evaluate the success of the prototype application: 1) establishing 
a help desk and 2) conducting a user survey. The help desk personnel will not only 
provide technical support to the end-users, but will also collect data on prototype 
application problems. Suggested areas for improvement will be incorporated in the 
multi-user application. 

The user survey is a more formal mechanism for evaluating the prototype system. 
However, the survey will not be conducted until the prototype system has been 
operational for several months and end-users are thoroughly familiar with the application. 
Therefore, help desk comments will provide feedback sooner than the user survey. 



E. LESSONS LEARNED FROM IMPLEMENTATION 

The prototype system was functional and capable of meeting the system owner’s 
basic requirements for data entry and reporting within the six week deadline. However, 
incorporating more robust capabilities and completing the finished product took 
considerably longer. A calculation of development hours required revealed that 
approximately 1050 hours were needed to fully develop the prototype system from the 
analysis phase through implementation. The function point and comprehensive cost 
model analyses conducted in the cost-benefit analysis had estimated that approximately 
1171 hours would be required to develop the system. Therefore, the conclusion is that 
the models were an effective tool for estimating development time in this case. 
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VI. PHASE II - THE MULTI-USER SYSTEM 



A. INTRODUCTION 

The decision to proceed with the development of a multi-user system was driven 
by the program manager’s desire to involve both the MTF and individual officer more 
closely in the EME educational process. While multi-user systems are generally more 
expensive and complex to implement than single-user systems, the benefits derived from 
increased productivity and reduced transaction costs can far outweigh the initial cost. 
There are four possible methods for supporting a multi-user database system: 
teleprocessing, client server computing, resource sharing, and distributed systems. 

Teleprocessing is a classic legacy implementation. With teleprocessing all 
communications control, operating system functions, applications, and DBMS 
components reside on a centralized computer. The processing is completed on the 
centralized central processing unit (CPU) and information is displayed on remotely 
connected dumb terminals. The user interface is often character-based and extremely 
primitive by today’s standards. [Ref. 9, p. 507] 

Client server computing consists of a network of computers connected over either 
a local area or wide area network. Local user machines are referred to as clients and 
“back-end” machines are called servers. In the database context, clients run application 
programs and servers store, manage, and process data. The server performs data integrity 
checking, concurrent access controls to records, and maintains the overhead data. A 
client server system tends to place the application closer to the end-user resulting in better 
performance and more sophisticated user interfaces. [Ref. 9, p. 507] 

Resource sharing systems also involve networked computers. The primary 
difference between resource sharing and client server systems is in the services provided 
by the “back-end” server. In the resource sharing environment, the server usually 
provides fewer services, requiring instead that more information be passed between 
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processors. Resource sharing systems traditionally require more bandwidth and have 
decreased throughput when compared to the other alternatives. [Ref. 9, p. 507] 

Distributed systems are implemented in two ways: distributed processing and 
distributed data. Distributed processing is the ability for more than one interconnected 
processor to be operating at a time. This means processing an application on more than 
one computer at a time. Distributing data is dividing the database and distributing 
portions throughout the system. Both approaches present significant problems for 
synchronizing data over a widely distributed system. The use of distributed database 
technology also requires developing system-wide rules to govern communication 
between nodes, data accessibility, program and file transfers, and common operating 
procedures. These factors usually mean increased cost over the other feasible alternatives. 
[Ref. 14, pp. 147-148] 

The client server model offers a multi-user solution which best fits the existing 
organizational structure and meets the program manager’s requirements. Because the 
prototype system was developed as a relational database it can be easily migrated to the 
client server model. Client server databases ensure excellent data integrity by enforcing 
stringent concurrent access rules. Client server systems are also easily scaleable from 
local area to wide area networks. Network traffic is less in client server systems than in 
resource sharing which is a significant concern with the small amount of available 
bandwidth in most wide area networks. Moreover, the client server model is not as 
complex as distributed systems and reduces the inherent synchronization problems. 

This chapter analyzes and defines the requirements for the multi-user system 
based on the client server model. Coding of the multi-user application will be 
accomplished by programmers at DMDC West based on the prototype system design and 
information provided in this chapter. DMDC has considerable experience in developing 
DOD client server applications and will provide assistance throughout the systems 
development process under a partnership agreement with the EME program. 
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B. ANALYSIS PHASE 



The SDLC is an iterative process whereby phases are re-visited as the 
environment changes and the deployment of a system proceeds. This section examines 
issues pertinent to the development of the multi-user system. 

The EMETRAK multi-user system will be a transaction-based processing 
application consisting of two parts: a Windows-based client distributed to Navy MTFs 
and a central database server. Connectivity between the client applications and database 
server will be accomplished over the existing Navy-wide medical network or via 
commercial switched networks (Figure 22). 
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Figure 22. Logical Client Server Topology 



In a transaction processing system, transactions consist of a query string sent by 
the client and a data set returned by the server. Figure 23 illustrates the general sequence 
of events in a client server system when an end-user accesses the database server over the 
network. 
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Client system 



Transaction 



— ► Server system 



Transaction 



— ► Client system 



Figure 23. Client Server Transaction Sequence [Ref. 1 1] 

If a transaction processing application is properly designed, the fact that the data 
is remotely located on a server will be transparent to the user. However, this requires that 
the application be optimized to reduce the bandwidth requirements and hence the 
response time over the network. 

Responsiveness of transaction processing systems is affected by several factors 
including: transaction size, transaction rate, concurrent network traffic, and the capacity 
of the network connection. Transaction size can be thought of as the physical length of 
the query string and the size of the data set that is returned. The transaction rate is the 
number of requests processed by the system in a specified time period. Concurrent 
network traffic is the volume of data on the network with which the transaction must 
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compete. The capacity of a network connection usually ranges from 9600 bits per second 
(modem connection) through several gigabits per second for advanced optical networks. 
The current NMDN capacity through DISN is only 56 kbps. 

An application’s bandwidth requirements are of much greater concern over a 
WAN because the available bandwidth is usually much smaller (almost 1 0 times smaller) 
than local area networks. Bandwidth concerns lead to an analysis of the existing 
prototype for transaction size and the NMDN for traffic volume. 



1. Prototype Peer to Peer Test 

Testing was conducted on the prototype system to determine an approximate 
transaction size and system response time. It has to be noted that the prototype system 
was not designed to operate over a network; therefore, it was not optimized for the peer- 
to-peer network configuration in which it was tested. However, the test was adequate to 
provide some initial planning data. The test revealed that the average transaction size of 
the prototype was quite large at approximately 50 kilobits (kb). Transactions of this size 
resulted in slow response time over a 14,400 modem direct dial-up connection. 

It was assumed that users would be willing to endure a substantial wait (as long as 
one minute) on initial start-up to download the data set to their local machines, but would 
then expect almost immediate response when toggling through records. The test proved 
that the transaction size in the multi-user system must be considerably smaller than 50 kb 
to achieve acceptable response after initial start-up delays. 

While unable to exactly determine the transaction rate for the EMETRAK multi- 
user system at this stage, it is anticipated to be low based on the nature of the application 
and the expected number of simultaneous users (16). 
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2 . 



Current NMDN Usage 



Bandwidth usage was examined over several of the existing NMDN wide area 
connections. NMIMC used HP OpenView® network monitoring software to collect the 
data from three sites over a five day period and provided the information at the request of 
the EME program office. Table 6 is a summary of the findings. 
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Table 6. NMDN Network Traffic Summary 



Although more extensive monitoring is required, it is assumed that the data is 
representative of normal network traffic volume. The initial investigation shows that the 
NMDN has excess capacity to support the EMETRAK multi-user application unless 
network traffic increases significantly. 
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3. 



Proposed Changes in Bandwidth 



NMIMC recognizes that the current 56 kbps connections will not support planned 
future applications such as multi-media telemedicine and is planning to increase the 
capacity during the next several fiscal years. Table 7 shows the planned NMDN DISN 
upgrades. 



Activity 


State 


Current Capacity 


Planned Upgrade 


NH Bremerton 


WA 


56 kbps 


512 kbps 


NH Oak Harbor 


WA 


56 kbps 


256 kbps 


NH Lemoore 


CA 


56 kbps 


256 kbps 


NH Camp Pendleton 


CA 


56 kbps 


512 kbps 


NMC San Diego 


CA 


56 kbps 


512 kbps 


NH Corpus Christi 


TX 


56 kbps 


256 kbps 


NH Pensacola 


FL 


56 kbps 


512 kbps 


NH Millington 


TN 


56 kbps 


256 kbps 


NH Camp Lejeune 


NC 


56 kbps 


512 kbps 


NMC Portsmouth 


VA 


56 kbps 


512 kbps 


NH Patuxent River 


MD 


56 kbps 


256 kbps 


NNMC Bethesda 


MD 


56 kbps 


512 kbps 


NH Groton 


CN 


56 kbps 


512 kbps 


NH Great Lakes 


IL 


56 kbps 


512 kbps 



Table 7. NMDN DISN Planned Bandwidth Increases 



The multi-user application will benefit from the planned increase in WAN 
capacity, however, it must still be designed to operate within the current bandwidth 
limitations. Moreover, not every MAN is scheduled to receive an increase in capacity. 



C. DEFINITION PHASE 

This section specifies the multi-user application requirements that will be 
delivered to DMDC West for design and implementation. The process and data models 
for the single-user system are also valid for the multi-user application and will be 
referenced in this section as well. 
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1 . 



Connection Methods 



EMETRAK requires two connection means from the client front-end application 
to the database residing on the back-end server. The primary connection protocol desired 
for the application is transmission control protocol/intemet protocol (TCP/IP) through the 
existing NMDN via DISN or the Internet. An alternate method to ensure redundancy 
should be implemented through a dial-up connection using a standard modem and point 
to point protocol (PPP). 



2. Database Views 

Different views of the database are required in the multi-user application. Three 
views of the data are envisioned: program management, enterprise, and organizational 
views. The views correspond roughly to three user groups: the EME program 
management staff, top level Navy Medical Department executives, and the individual 
MTFs. Each view should be based on a set of user permissions programmed into the 
client application and enforced by the database server. 

The views are unique, but are not necessarily mutually exclusive. For example, 
the program management staff would have privileges to access all views and to 
manipulate the database (except for those specifically reserved system administrator 
functions). Access to a database view should be determined through a combination of the 
user’s UIC and password during system log on. 

• Program Management view - The program management view of the database 
would allow the user to see all tables, queries, forms, and reports in the 
application. The program management view would be available to the EME 
program management staff at NPS, the program manager at NSHS, Bethesda, and 
the EME system administrator (with additional functions provided). 
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• Enterprise view - The enterprise view is envisioned as an executive level view. 
The enterprise view would provide screen reports about the program derived from 
statistical summaries. The enterprise view would allow the user to “drill” down 
and see officers filtered by their designator number or see information about an 
individual officer, if desired. The enterprise view would be available to the 
Surgeon General, the Medical Department Corps Chiefs, and other selected 
executives at BUMED, BUPERS, and NSHS, Bethesda, MD. 

• Organizational view - The organizational view would center on the officers 
assigned to a specific command (UIC). The organization would be able to view 
all information that pertains to officers in the command or within a specific 
designator group subject to a filter. Consequently, the OFFICER and CLASS 
table views, system queries, and reports should be based on the appropriate filter 
and the user’s password. All UIC, COURSE, and COMPETENCYCAT tables, 
however, could be viewed in the organizational view. The organizational view 
would be available to all MTFs and BUMED specialty advisors. MTFs would 
view information filtered by UIC and specialty advisors view by the appropriate 
designator number. 

Access to the database views should be controlled through a user interface 
described by the state transition diagram in Appendix J. 



3. User Functions and Responsibilities 

This section specifies who may perform certain functions in the multi-user 

system. 
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a. Data Maintenance Function (Figure 7) 

• Update Officer Information (Process 1.1) 

- Add Officer - BUPERS and EME Staff 

- Modify Officer Information - BUPERS, EME Staff, and MTF 

- Delete Officer - EME Staff 

- Change Officer Location - BUPERS 

• Update Course Information (Process 1.2) 

- Add Course - EME Staff (System Administrator) 

- Modify Course Information - EME Staff (System Administrator) 

- Assign Course to Competency - EME Staff (System 
Administrator) 

• Update Command Information (Process 1.3) 

- Add Command - EME Staff (System Administrator) 

- Modify Command Information - MTF and EME Staff (System 
Administrator) 

- Delete Command - EME Staff (System Administrator) 

• Generate Class Information (Process 1.4) 

- Add Class - MTF and EME Staff 

- Modify Class Information - MTF and EME Staff 

- Delete Class - EME Staff (System Administrator) 

• Import/Export Information (Process 1.5) 

- Create Backup and Archive (Process 1.5.1) - EME Staff (System 
Administrator) 

- Export data to dblll file format (Process 1.5.2) - All users 
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- Import BUPERS OFFICER data file (Process 1.5.3) - EME Staff 
(System Administrator) 

4. Required Queries 

The queries listed in this section are organized according to the EMETRAK 
process model (Figure 8). They are further grouped according to the database views that 
apply. Queries (structured or interactive) may be combined during implementation to 
support various screen and hard copy report formats as required. Implementation of an 
interactive menu of queries and reports similar to the “SelectaRun” form in the prototype 
application is desired. 



a. Run Structured Queries (Process 2.1) 

(1) Generic queries 

• All course modules 

• All course modules grouped by course sponsor 

• All course modules grouped by competency category 

• All competency categories 

• All command information (UIC number, name, address, etc.) 

• All course modules delivered in the last 90 days and their 
locations 

(2) Queries common to the program management and 

enterprise views 

• All officers in alphabetical order 

• All officers in alpha order grouped by command (UIC) 
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• All officers in alpha order and completed modules grouped by 
command (UIC) 

• All officers in alpha order and completed modules 

• All officers in alphabetical order grouped by designator 

• All officers in a command (UIC) grouped by designator 

• All officers in alpha order in a command and completed 
modules grouped by designator 

(3) Queries common to the program management and 

organizational views 

• All classes delivered in the last 90 days 



b. Generate Interactive Queries (Process 2.2) 

(1) Generic queries 

• All course modules grouped by course sponsor (select on 
course sponsor input) 

• All course modules grouped by competency (select on 
competency input) 



enterprise views 



(2) Queries common to the program management and 



• All officers in alpha order (select on UIC input) 
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• All officers in alpha order and completed modules (select on 
UIC input) 

• All course modules completed by a specific officer (select on 
SSN input) 

• All officers based on profile query requiring one or more of the 
following input: 

Rank 

Service 

Designator 

UIC 

Health Service Region 

Course Module (or range of modules) 

(3) Queries common to the organizational view (filter by UIC 

Number) 

• Officers in alpha order (select on designator input) 

• Officers in alpha order (select on rank input) 

• Officers in alpha order (select on course module or competency 
category input) 



c. Generate Statistical Reports (Process 2.3) 

(1) Generic queries 

• The average number of EME hours attained per officer 

by: total officers, rank, designator, UIC, and HSR 

• The number of officers that have completed a specific course 
(grouped by course) 
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by: total officers, rank, designator, UIC, and HSR 

• The number of officers that have completed a competency 
category (grouped by category) 

by: total officers, rank, designator, UIC, and HSR 

• The percentage of officers that have completed a specific 
course (grouped by course) 

by: total officers, rank, designator, UIC, and HSR 

• The percentage of officers that have completed a competency 
category (grouped by category) 

by: total officers, rank, designator, UIC, and HSR 

• The number of courses in the EME curriculum by course 
sponsor 

• The number of hours provided, sub-divided by sponsor by: 
fiscal quarter, fiscal year, and between two dates 

5. Required Reports 

The reports listed in this section are organized according the EMETRAK process 
model (Figure 9). The report formats must conform to the style presented in the 
Appendix G. Structured, Interactive and Statistical reports are listed in Tables 8, 9, and 
10, respectively. The abbreviations P, E, and O in the tables correspond to the program 
management, enterprise, and organizational views. 



a. Generate Structured Reports (Process 3.1) 

Structured reports are pre-formatted reports that do not require user input. 
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Number 


Report Name 


Views 


1 


Officers in Alphabetical Order 


P, E, 0 


2 


Officers in Alphabetical Order Grouped by Designator 


P, E, 0 


3 


Officers in Alphabetical Order Grouped by Command 


P,E 


4 


Officers in Alphabetical Order and Completed Modules 


P, E, 0 


5 


Course Modules (with descriptions) 


P, E, 0 


6 


Competency Categories 


P, E, 0 


7 


Course Modules by Competency Category 


P. E,0 


8 


Course Modules by Sponsor 


P, E, 0 


9 


Participating Commands (UIC) 


P, E, 0 


10 


Course Completion Letter 


P,0 


11 


Completion Certificate 


P, o 


12 


Official T ranscript 


P 



Table 8. Structured Reports 



b. Generate Interactive Reports (Process 3.2) 



Interactive reports require user input to determine selection criteria for the 
data set in the report. 



Number 


Report Name 


Views 


13 


Officers and Completed Modules Grouped by Designator 
(input designator) 


P, E, 0 


14 


Officers and Completed Modules Grouped by Command 
(input UIC) 


P, E 


15 


Officers and Completed Modules Grouped by Rank (input 
rank) 


P. E.O 


16 


Completed Modules by a Specific Officer (input SSN) 


P, E, 0 



Table 9. Interactive Reports 



c. Generate Statistical Reports (Process 3.3) 

Statistical reports provide summaries of the data in tabular (T), line graph 
(L), bar (B), or pie chart (P) format. Appendix K provides examples of the statistical 
format types. 
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Number 


Report Name 


Views 


Type 


17 


Course Modules Provided in Last 90 Days 


P, E, 0 


T 


18 


Classes Provided in the Last 90 Days 


P, E, 0 


T 


19 


Average EME hours attained per officer by: total 
officers, rank, designator, UIC, and HSR 


P.E 


T/L 


20 


Number of officers that have completed a specific 
course (grouped by course) by: total officers, rank, 
designator, UIC, and HSR 


P, E 


T 


21 


Number of officers that have completed a 
competency category (grouped by category) by: 
total officers, rank, designator, UIC, and HSR 


P, E 


T 


22 


Percentage of officers that have completed a 
specific course (grouped by course) by: total 
officers, rank, designator, UIC, and HSR 


P, E 


P 


23 


Percentage of officers that have completed a 
competency category (grouped by category) by: 
total officers, rank, designator, UIC, and HSR 


P, E 


P 


24 


Number of courses in the EME curriculum by 
course sponsor 


P, E 


B 


25 


Number of hours in the EME curriculum by course 
sponsor 


P, E 


B 


26 


Number of hours provided, sub-divided by sponsor 
by: fiscal quarter, fiscal year, and between two 
dates 


P, E 


T 



Table 10. Statistical Reports 



6. Security Requirements 

National Telecommunications and Information Systems Security Publication 2 
(1986) specifies that sensitive but unclassified information must be protected from 
disclosure, loss, misuse, alteration, or destruction. The EMETRAK database contains 
sensitive but unclassified information protected under the Privacy Act of 1974. 
Therefore, the EMETRAK system must comply with the security class C2 controlled 
access protection. [Ref. 13] 

Access controls must be enforced at both the client and database server level. 
Information security should be enforced through the following mechanisms: 

• Discretionary access control - Define and control access between named users 
and named objects (files, tables, forms, reports, etc.) down to the single user 
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level in the system. The enforcement mechanism should be through the use of 
group and user permissions. 

• Identification and authentication - Use a protected mechanism (log on and 
passwords) to authenticate a user’s identity. The log on procedure should be 
implemented in the client application. Authentication data must be protected 
from access by unauthorized users and should be implemented in the server 
application. 

• Data security - The system must be able to encrypt the officer SSN, last name, 
and UIC prior to transmission. This feature prevents name, SSN, and UIC 
association during data transmission between the client site and the server. 

• Audit - The system must have a transaction tracking capability to audit 
modifications, insertions, and deletions from the database. Identification of 
the time, date, user ID, and type of transaction accomplished is required. 



7. Client Application Features 

The client must be a Windows-based application that is capable of running on the 
Windows® 3.1 1 operating system using a 80386 or later version processor with 8 MB of 
RAM. The intention is to distribute run-time executable versions of the EMETRAK 
client via floppy disk, file transfer protocol, or electronic mail. Therefore, the client 
must contain its own set-up utility. 

The client user interface should emulate the prototype application and support a 
local query and report generation capability. The application must support ANSI SQL 89 
and the Open Database Connectivity (ODBC) protocol. Finally, an identification and 
authentication feature must be incorporated in a log on routine. 
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8 . 



Database Server Application Features 



Selection of the server hardware and operating system will be based on the system 
requirements of the database server application. Specific procurement recommendations 
for a server and operating system are beyond the scope of this thesis and will not be 
addressed. However, a server database application should have the following features: 

• Support client server computing over a wide area network using TCP/IP 

• Must be C2 compliant 

• Allow 1 6 simultaneous users 

• Provide fine-grained database privileges for objects, queries, and access 

• Provide concurrency control through row (record) level locking 

• Provide for centralized security management 

• Provide an adjustable auditing capability 

• Support stored procedures activated by client application remote procedure 
calls 

• Provide parallel query support 

• Provide on-line back-up capability 

• Support job scheduling for reports and back-ups 



D. RECOMMENDATIONS FOR THE REMAINING SDLC PHASES 

The remaining stages of development for the multi-user system are design, 
coding, testing, implementation, and support. DMDC programmers will begin design 
and coding once the requirements are completed. They estimate that eight weeks will be 
required to produce an initial version of the multi-user system. Once the system is 
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functional, it will undergo extensive system testing to verify and validate the 
requirements. 



1. System Testing 

System testing will be accomplished in two stages: alpha and beta testing. Alpha 
testing involves reviewing the basic functionality of the system over both types of 
connection methods: TCP/IP (Internet) and PPP (dial-up). DMDC will provide a 
functional client application to the EME staff and the EMETRAK development team for 
testing. Data will be migrated from the single user system to an Oracle Server 7.2 
RDBMS running on a Sparc 20 workstation located at DMDC West. DMDC has agreed 
to maintain the database during the entire testing period estimated to last approximately 
six months. Five test nodes are recommended for the alpha test; four at NPS and one at 
NSHS, Bethesda. The test nodes are the EME program coordinator, EME administrative 
support staff (2 nodes), EME program manager at NSHS, and the EMETRAK 
development team. Special attention must be focused on evaluating system response over 
the wide area connection during the alpha test. Recommended improvements from the 
alpha test version should be incorporated prior to the beta test stage. 

Beta testing should involve a limited number of MTF sites to further test system 
functionality over the existing NMDN architecture. During the beta test stage, a decision 
regarding the procurement of server hardware, software, and location will be required. 
Further, system support decisions will be required concerning database/system 
administration and technical support personnel at that stage. Two goals of the beta test 
should be to migrate the existing database from DMDC to an EMETRAK server and to 
have an adequate technical support structure in place before beginning system 
installation. 
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2. System Installation 



Two options are provided for installation. One option is the procurement of a 
dedicated EMETRAK server and another is outsourcing server support to a DOD 
organization. 

The dedicated server option requires a substantial capital expenditure which has 
been planned and budgeted. The advantage offered seems to be increased management 
control because the EME program office is taking ownership of the administration 
process. The disadvantage of owning a dedicated server is the major increase in 
maintenance and personnel costs over the single-user system. Training cost for a 
database/systems administrator is another factor in selecting an installation option. 
DMDC database administrators estimate that approximately four months of training are 
needed on Oracle or comparable RDBMS systems to adequately prepare a person for the 
database administrator position. Training for the server operating system and system 
administration is also required. Developing and maintaining expertise in these areas will 
require a significant investment of time and money. 

An alternative that should be investigated is migrating the database from DMDC 
to the NPS Oracle 7.3 DBMS running on the University’s Digital Equipment Corporation 
(DEC) Alpha server. An agreement could be arranged whereby the EME program 
reimburses NPS for data storage, computing support, and technical support services for 
the back-end server. Outsourcing for service is advantageous because the day-to-day data 
and system administration is shifted from the program office to the service provider. 
Although further study is required, this option seems to offer a cost effective alternative 
to procuring and maintaining a dedicated server. 



86 



VII. SUMMARY 



A. PROJECT CONCLUSIONS 



1. Service-based Learning 

Service-based learning is a form of job instruction training where learning and 
experience are gained while providing a service [Ref. 14, pp. 252-253], It is not as 
narrowly focused or closely supervised as on-the-job-training, but it enables a person to 
thoroughly explore a subject area and then apply what has been learned to a project. The 
EME program provided just such an opportunity. 

The EMETRAK project facilitated my development as a systems analyst by 
providing an opportunity to learn about design and implementation issues during the 
actual deployment of a system. Service-based learning is not appropriate in every 
situation, particularly when a project is under tight schedule or budget constraints. 
However, in the academic environment, service-based learning proves to be a practical 
way to provide experience for students learning the role of a systems analyst. 

This topic was ideal for providing systems analysis experience because of its 
scope and the fact that each stage of the SDLC was explored. It provided design as well 
as project management experience and required knowledge of many different 
technologies. The project required study of process and data modeling techniques, 
database, application and network design. Further, it enabled the application of analysis 
techniques and project management tools learned in the Information Technology 
Management curriculum to a real world example. Finally, the project required interaction 
with program managers, the system owner, end-users, and programmers to successfully 
develop an application that met the requirements of the Navy Medical Department. 
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2 . 



The Prototype System as a Development Tool 



Prototypes are developed by programmers to solicit feedback and assist in 
application and interface design. The Phase I prototype system served this purpose, but it 
was also used as a model for Phase II. Once the prototype application was refined, it 
became the vehicle for describing system requirements for programmers developing the 
multi-user version. Programmers studied the written specifications and then referred to 
the prototype to see the desired functionality. 

The use of a prototype greatly streamlined the development process for both 
phases of EMETRAK. Access 2.0® was an excellent prototyping and rapid application 
development tool. Speed of development was extremely important in order to meet the 
initial project milestones. However, the prototype application proved to be even more 
effective when used by the analyst to describe multi-user system requirements. 

3. System Owner and End-user Involvement 

This project reinforced the importance of managerial support and end-user 
involvement to the success of a systems development effort. The ability to articulate the 
benefits of the system and demonstrate a functional prototype after only a few weeks of 
programming helped gamer crucial political and economic support for the project at a 
time when formal approval and project funding were in doubt. Moreover, proving that 
the project was feasible established our credibility with the system owner which was 
critical to sustaining development over the life of the project. 

Involving end-users early in development helped avoid potential problem areas 
and allowed more detailed system specifications to be written. The detailed nature of the 
specifications reduced the number of changes and resulting delays during 
implementation. Further, end-user acceptance was enhanced because they were able to 
gain first-hand experience with the application and see the benefits as the system was 
being developed. 
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Management and end-user support was enhanced in this project because each was 
closely involved in the process and became partners in system development. 



4. Changing Scope of the Project 

One of the original research questions asked what type of information system 
would support the future needs of the EME program; a single user system, a multi-user 
system implemented over a LAN or a multi-user system implemented over a WAN? The 
answer really is all three. In the early stages of the project (FY-95), a single user system 
was adequate to meet the requirements for data collection and reporting for a limited 
number of participants. As the scope of the EME program increased in FY-96, the 
supporting staff grew and the number of end-users increased. A multi-user system 
implemented over a LAN at NPS proved adequate to support administration of the 
program. Remote access to the database from numerous end-user sites is still the desire 
for FY-97. While the exact deployment schedule of the multi-user system is in question, 
it will eventually be implemented over a wide area. 

The point is that the scope of any project will change and must be planned for 
during development. In the case of EMETRAK, the fundamental process and data 
models were designed to be scaleable. During implementation, the selection of the client 
server model permitted the multi-user system to be implemented over either a LAN or 
WAN as the number of end-users and their locations changed. 

The key to success seems to be understanding that the scope of a project will 
change and then anticipating how the system will be affected by the change. This was 
achieved in the EME project through a thorough analysis of the business problem and, 

most importantly, by having a vision and the support of the program manager and system 
owner. 
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B. AREAS FOR FURTHER RESEARCH 



1. Multi-user System Installation and Support Issues 

A significant number of EMETRAK life cycle management issues require further 
study. Alpha and Beta testing must be concluded and the multi-user system must still be 
installed and supported in the field. Installation issues which require further analysis are 
selection of the database server, NMDN network bandwidth usage, determining the 
EMETRAK deployment schedule, and development of a technical support infrastructure. 
System and code maintenance, client application version control, database maintenance, 
and analysis of future system requirements are system support issues that should be 
investigated. 



2. EMETRAK Integration Issues 

EMETRAK currently has a fairly narrow focus, however, its relational 
architecture makes it well suited to handle other types of data pertinent to the individual 
officer. The system is capable of tracking educational information from sources outside 
of the EME program, medical readiness data, or professional credentials of the Medical 
Department officer. Incorporating this type of information into a central repository 
warrants further study. 

Integration of EMETRAK data with other applications like the Reserve Training 
and Readiness System (RSTARS), the Navy Integrated Training and Assignment System 
(NITRAS Phase II), or the DOD integrated personnel system also have merit and provide 
areas for continued research. 



3. Application of World-Wide Web (WWW) Technologies 

The recent explosion of Web technologies provides another avenue for delivering 
EME information to the customer. Programming languages like Java allow the 
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development ol self-contained EMETRAK-like applets that can be distributed over the 
Web. This technology is advertised as providing platform independence (hardware and 
software) and enables unlimited distribution of the application with minimal overhead. 
This type of technology offers an exciting alternative to traditional client server 
computing and will likely change our inter-networking paradigms in the future. Web 
technologies and security issues should be investigated as one possible future 
implementation of the program. 



4. Distributed Database Technologies 

Applications like Lotus Notes® have dramatically reduced the cost and 
complexity of managing distributed databases. Features that include concurrent access 
controls, automatic data replication, job scheduling, and fault tolerance have made it 
popular with organizations operating in the distributed computing environment. 
Moreover, the ability to integrate data directly into electronic mail, word processing 
documents, and other applications makes the system all the more appealing. This type of 
technology is being used by a number of other DOD agencies and its applicability to the 
EME program and Navy Medicine should be researched. 
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APPENDIX A. INITIAL USER QUESTIONNAIRE 



This appendix contains the questions that were used during the initial interviews 
with the program manager and system owner to define the problem and limit its scope. 
The general categories were taken from Whitten. [Ref. 5] 

I. About the PEOPLE 

Who would be the end-users of this system? 

Would anyone be indirectly affected by the system? 

What existing system is in place (if any)? 

What people or political problems, opportunities, or directives triggered this project request? 
^^lopment? a8ement ^ US6rS ^ thiS Pr ° jeCt if h is approved for application 

II. About the DATA 

What are the key inputs to this system? 

What are the key outputs from this system? 

Is any data currently being captured and stored in computer files and/or databases? 

III. About the ACTIVITIES 

What is the purpose or mission of this business area (in non-computer terminology)? 

What are the goals and objectives of this business area? 
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Has any of this system been computerized already? 



IV. About the NETWORKS 



Will this project provide support for multiple locations? If so, where are they? 
How do the locations currently communicate? 

Are any computer networks currently in use? 
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APPENDIX B. PROPOSED MTF DEPLOYMENT SITES 



This appendix lists the proposed deployment sites for the EMETRAK multi-user 



system. 



UIC 


ACTIVITY 


STATE 


00162 


NMCL ANNAPOLIS 


MD 


00267 


NMCL KEY WEST 


FL 


48488 


NMCL KINGS BAY 


GA 


46491 


NMCL LONDON 


UK 


66898 


NMCL NEW ORLEANS 


LA 


68098 


NMCL PEARL HARBOR 


HI 


68101 


NMCL PHILADELPHIA 


PA 


66099 


NMCL PORT HUENEME 


CA 


00105 


NMCL PORTSMOUTH 


VA 


00231 


NMCL QUANTICO 


VA 


65575 


NMCL SEATTLE 


WA 


68349 


REDCOM 16 -MINNEAPOLIS 


MN 


61337 


NH BEAUFORT 


SC 


00168 


NNMC BETHESDA 


MD 


68095 


NH BREMERTON 


WA 


68093 


NH CAMP LEJEUNE 


NC 


68094 


NH CAMP PENDLETON 


CA 


68084 


NH CHARLESTON 


SC 


66094 


NH CHERRY POINT 


NC 


00285 


NH CORPUS CHRISTI 


TX 


00211 


NH GREAT LAKES 


IL 


61726 


NH GROTON 


CT 


68096 


NH GUAM 


MIC 


61564 


NH GUANTANAMO 


CU 


00232 


NH JACKSONVILLE 


FL 


68875 


NH KEFLAVIK 


1C 


66095 


NH LEMOORE 


CA 


68090 


NH LONG BEACH 


CA 


60002 


NH MILLINGTON 


TN 


66096 


NH NAPLES 


IT 


68086 


NH NEWPORT 


Rl 


66097 


NH OAK HARBOR 


WA 
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UiC 


ACTIVITY 


STATE 


00619 


NH OAKLAND 


CA 


68470 


NH OKINAWA 


JA 


65492 


NH ORLANDO 


FL 


66098 


NH PATUXENT RIVER 


MD 


00203 


NH PENSACOLA 


FL 


00183 


NMC PORTSMOUTH 


VA 


65428 


NH ROOSEVELT ROADS 


PR 


66101 


NH ROTA 


SP 


00259 


NMC SAN DIEGO 


CA 


39163 


NH SIGONELLA 


IT 


35949 


NH TWENTYNINE PALMS 


CA 


68292 


NH YOKOSUKA 


JA 


0608A 


NNDC BETHESDA 


MD 


68443 


NDC BREMERTON 


WA 


68410 


NDC CAMP LEJEUNE 


NC 


62594 


NDC CAMP PENDLETON 


CA 


65999 


NDC CHARLESTON 


SC 


68326 


NDC GREAT LAKES 


IL 


62328 


NDC GUAM 


Ml 


68444 


NDC JACKSONVILLE 


FL 


62947 


NDC LONG BEACH 


CA 


68442 


NDC NAPLES 


IT 


66023 


NDC NEWPORT 


Rl 
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APPENDIX C. EXISTING NMDN NETWORK TOPOLOGIES 
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Figure C-l. North Atlantic Metropolitan Area Network (MAN) 
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Figure C-2. Great Lakes Metropolitan Area Network (MAN) 
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Figure C-3. Bethesda Metropolitan Area Network (MAN) 
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Figure C-4. Mid-Atlantic Metropolitan Area Network (MAN) 
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Figure C-5. Tidewater Metropolitan Area Network (MAN) 
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Figure C-6. South Atlantic Metropolitan Area Network (MAN) 



BRDENCL NAS Corpus Christi TX 










103 



Figure C-7. Gulf Coast Metropolitan Area Network (MAN) 







104 



Figure C-8. Puget Sound Metropolitan Area Network (MAN) 
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Figure C-9. San Diego Metropolitan Area Network (MAN) 



(WinNT BMC/BDC-Souda Bay) 
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Figure C-10. Europe Metropolitan Area Network (MAN) 



NSHS Officer Info 



APPENDIX D. DATA FLOW DIAGRAMS 
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Figure D-1. Level 1 Process 1 Chart 
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Figure D-2. Level 1 Process 2 Chart 
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Figure D-3. Level 1 Process 3 Chart 
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Figure D-4. Level 2 Process 1.1 Chart 
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Figure D-5. Level 2 Process 1.2 Chart 
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Figure D-6. Level 2 Process 1.3 Chart 
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Figure D-7. Level 2 Process 1.4 Chart 
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Figure D-8. Level 2 Process 1.5.1 Chart 
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Figure D-9. Level 2 Process 1.5.2 Chart 
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Figure D-10. Level 2 Process 1.5.3 Chart 
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Figure D-11. Level 2 Process 1.5.4 Chart 
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APPENDIX E. PROTOTYPE DATA DICTIONARY 



This appendix lists all of the data elements in the EMETRAK prototype system 
by table and field name. 



Data Item 


Table Name 


Field Name 


Type 


Size 


Index 


1 


CLASS 


ClassState 


Text 


2 




2 


CLASS 


SSN 


Text 


11 


Primary Key 


3 


CLASS 


ClassZip 


Text 


10 




4 


CLASS 


ClassCity 


Text 


25 




5 


CLASS 


ClassStreet 


Text 


35 




6 


CLASS 


HostCommand 


Text 


35 




7 


CLASS 


Instructor 


Text 


25 




8 


CLASS 


ClassDate 


Date/Time 


8 




9 


CLASS 


CourselD 


Text 


6 


PrimaryKey 


10 


CLASS 


FormLetter 


Yes/No 


1 




11 


COMPCOURSE 


Competency 


Text 


50 


Prim ary Key 


12 


COMPCOURSE 


CourselD 


Text 


6 


PrimaryKey 


13 


COMPETENCYCAT 


Competency 


Text 


50 




14 


COURSE 


CourseName 


Text 


100 




15 


COURSE 


CourseSponsor 


Text 


50 




16 


COURSE 


EMEProglnfo 


Number (Integer) 


2 




17 


COURSE 


CourseDescription 


Memo 


- 




18 


COURSE 


Hours 


Number (Double) 


8 




19 


COURSE 


CourselD 


Text 


6 


PrimaryKey 


20 


COURSE 


CEUCredits 


Number (Double) 


8 




21 


EMEPROGINFO 


EMEProgOffPhone 


Text 


13 




22 


EMEPROGINFO 


EMEDSNPhone 


Text 


8 




23 


EMEPROGINFO 


EMEProglnfo 


Number (Integer) 


2 


PrimaryKey 


24 


EMEPROGINFO 


ProgCoordLName 


Text 


25 




25 


EMEPROGINFO 


ProgCoordFName 


Text 


15 




26 


EMEPROGINFO 


ProgCoordMInit 


Text 


1 




27 


EMEPROGINFO 


ProgCoordTitlel 


Text 


10 




28 


EMEPROGINFO 


ProgCoordTitle2 


Text 


35 




29 


EMEPROGINFO 


ProgCoordTitle3 


Text 


25 




30 


EMEPROGINFO 


NPSDeptName 


Text 


50 




31 


LISTOFREPORTS 


ReportName 


Text 


50 




32 


LISTOFREPORTS 


ReportNumber 


Number (Integer) 


2 




34 


OFFICER 


SSN 


Text 


11 


PrimaryKey 


35 


OFFICER 


Email 


Text 


25 




36 


OFFICER 


JobTitle 


Text 


50 




37 


OFFICER 


SubSpecialty 


Text 


6 




38 


OFFICER 


Designator 


Text 


5 





119 



39 


OFFICER 


BSC 


Text 


6 




40 


OFFICER 


Service 


Text 


4 




41 


OFFICER 


Rank 


Text 


4 




42 


OFFICER 


Minitial 


Text 


1 




43 


OFFICER 


FirstName 


Text 


15 




44 


OFFICER 


LastName 


Text 


25 




45 


OFFICER 


UIC 


Text 


6 




46 


UIC 


UICName 


Text 


45 




47 


UIC 


HealthSvcRegion 


Number (Integer) 


2 




48 


UIC 


UlCType 


Text 


1 




49 


UIC 


UlCFax 


Text 


13 




50 


UIC 


UlCDSNPhone 


Text 


7 




51 


UIC 


UlCPhone 


Text 


13 




52 


UIC 


UICZip 


Text 


10 




53 


UIC 


UlCState 


Text 


2 




54 


UIC 


UlCStreet 


Text 


30 




55 


UIC 


UlCTitle 


Text 


50 




56 


UIC 


UIC 


Text 


6 


PrimaryKey 


57 


UIC 


UICCity 


Text 


25 
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APPENDIX F. PROTOTYPE SYSTEM QUERIES 



This section describes the significant system queries written for the EMETRAK 
prototype system. The queries were written in the MS Access version of SQL which is 
slightly different than the ANSI standard. 



1. qryOfficers by Alpha 



This query lists the officers in the database in alphabetical order. The result is 
ordered by last name then first name. 



SELECT DISTINCTROW OFFICER.SSN, OFFICER.LastName, OFFICER.FirstName, 
OFFICER.Minitial, OFFICER. Rank, OFFICER.BSC, OFFICER.Designator, 

OFFICER. SubSpecialty, OFFICER. JobTitle, OFFICER.Email, OFFICER.UIC, 
UIC.UICName, UIC.UICStreet, UIC.UICCity, UIC.UICState, UIC.UICZip, 
UIC.UICPhone, UIC.UICDSNPhone 

FROM UIC INNER JOIN OFFICER ON UIC.UIC = OFFICER.UIC 
ORDER BY OFFICER.LastName, OFFICER.FirstName; 



2. qryOfficersbyUIC 



This query lists the officers in the database in alphabetical order grouped by 
command and health service region. 



SELECT DISTINCTROW UIC.UICName, UIC.UICState, UIC.HealthSvcRegion, 
OFFICER.* 

FROM UIC INNER JOIN OFFICER ON UIC.UIC - OFFICER.UIC 
ORDER BY UIC.HealthSvcRegion, OFFICER.LastName; 
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3. qryEMELongCourses 



This query lists all full-length courses in the EME program syllabus ordered by 
course ID number. 



SELECT DISTINCTROW COURSE.CourselD, COURSE.CourseName, 
COURSE.CourseDescription, COURSE.Hours, COURSE.CourseSponsor 
FROM COURSE 

WHERE ((COURSE.CourselD Not Like "*a")) 

ORDER BY COURSE.CourselD; 



4. qryClassLast90Days 



This query lists all classes completed in the last 90 days ordered by class date, 
course ID number, and officer’s last name. 



SELECT DISTINCTROW CLASS.ClassDate, CLASS.CourselD, 
COURSE.CourseName, OFFICER.LastName, OFFICER.FirstName, OFFICER.Minitial, 
OFFICER.Rank, OFFICER.Designator, CLASS.SSN, OFFICER.JobTitle, 
OFFICER.UIC, CLASS. Instructor, COURSE.Hours, CLASS. HostCommand, 

CLASS. ClassStreet, CLASS.ClassCity, CLASS. ClassState, CLASS.ClassZip 
FROM COURSE INNER JOIN (OFFICER INNER JOIN CLASS ON OFFICER.SSN = 
CLASS.SSN) ON COURSE.CourselD = CLASS.CourselD 
WHERE ((C L A S S . C lassDate>Date()-90)) 

ORDER BY CLASS.ClassDate, CLASS.CourselD, OFFICER.LastName, 
OFFICER.FirstName; 



5. qryClassDateName 



This query lists the classes completed by a specific officer based on last name or 
SSN input. 



SELECT DISTINCTROW OFFICER.SSN, OFFICER.LastName, OFFICER.FirstName, 
OFFICER.Minitial, OFFICER.Rank, COURSE.CourselD, CLASS.ClassDate, 
COURSE.CourseName, OFFICER.UIC 
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FROM COURSE INNER JOIN (OFFICER INNER JOIN CLASS ON OFFICER.SSN = 
CLASS. SSN) ON COURSE.CourselD = CLASS.CourselD 

WHERE ((OFFICER.SSN Like InputBox$("Enter the Officer's SSN or Press Enter for 
Name Only Search'V'SSN","") & "*") AND (OFFIC ER. LastN ame Like 
InputBox$(" Enter the Officer's Name or Press Enter for a SSN Search", "Officer 
Name","") & "*"» 

ORDER BY OFFICER.LastName, OFFICER.FirstName; 



6. qryCoursesbyCompetency 



This query lists all EME courses grouped by competency category. 



SELECT DISTINCTROW COMPCOURSE.Competency, COURSE.CourselD, 
COURSE.CourseName, COURSE. Hours 

FROM COURSE INNER JOIN COMPCOURSE ON COURSE.CourselD = 
COMPCOURSE.CourselD 

GROUP BY COMPCOURSE.Competency, COURSE.CourselD, 
COURSE.CourseName, COURSE. Hours 
HAVING ((COURSE.CourselD Not Like "*a"» 

ORDER BY COURSE.CourselD; 



7. qryCompletedModulesbyOfficer 



This query provides a comprehensive listing of all officers in the database and the 
EME courses that they have completed. The results are ordered by last name and course 
ID number. 



SELECT DISTINCTROW OFFICER.*, CLASS.*, COURSE.*, UIC.* 

FROM COURSE INNER JOIN ((UIC INNER JOIN OFFICER ON UIC.UIC = 
OFFICER.UIC) INNER JOIN CLASS ON OFFICER.SSN = CLASS.SSN) ON 
COURSE.CourselD = CLASS.CourselD 

WHERE ((OFFICER.LastName Like InputBox$(" Enter a Last Name or Press Enter for 
all Officers", "Officer Name","") & "*")) 

ORDER BY OFFICER.LastName, OFFICER.FirstName, OFFICER.Minitial, 
CLASS.CourselD; 
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8. qryProfiler 



This query selects the record set based on user input. The result is a list of 
officers that are of a certain rank and designator, in a specific HSR, and have completed a 
specific course module. 



SELECT DISTINCTROW UIC.*, OFFICER.*, CLASS.*, COURSE.* 

FROM COURSE INNER JOIN (UIC INNER JOIN (OFFICER INNER JOIN CLASS 
ON OFFICER.SSN = CLASS.SSN) ON UIC.UIC = OFFICER.UIC) ON 
COURSE.CourselD = CLASS.CourselD 
WHERE ((CL AS S .CourseID=[F orms] ! [Profiler] ! [Module])) OR 
((OFFICER.Rank=[Forms] ! [Profiler] ! [Rank])) OR 
((UIC.HeahhSvcRegion=[Forms]! [Profiler]! [HSR])) OR 
((OFFICER.Designator=[Forms]! [Profiler]! [Designator])) 

ORDER BY OFFICER.LastName, OFFICER.FirstName; 



9. qryCommands 

The query results in a listing of all MTFs in the database. 



SELECT DISTINCTROW UIC.* 
FROM UIC; 



10. qryClassCourse 



This query lists course modules completed by an officer in course ID order for 
display on the Officer Record subform. 



SELECT DISTINCTROW CLASS.SSN, CLASS.ClassDate, COURSE.CourselD, 
COURSE.CourseName, COURSE.Hours, COURSE.CEUCredits, 
COURSE.CourseSponsor, COURSE. CourseDescription, CLASS. Instructor, 

CLASS. HostCommand, CLASS. ClassStreet, CLASS. ClassCity, CLASS. ClassState, 
CLASS. ClassZip 

FROM COURSE INNER JOIN CLASS ON COURSE.CourselD = CLASS.CourselD 
ORDER BY COURSE.CourselD; 
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11. qryCompetencyCount 



This query totals the number of courses and hours completed for display on the 
competency count subform. 



SELECT DISTINCTROW COMPCOURSE.Competency, CLASS.SSN, 
Count(COURSE.CourselD) AS HowManyCourses, Sum(COURSE.Hours) AS 
TotalHours 

FROM (COURSE INNER JOIN CLASS ON COURSE.CourselD = CLASS.CourselD) 
INNER JOIN (COMPETENCYCAT INNER JOIN COMPCOURSE ON 
COMPETENCYCAT.Competency = COMPCOURSE.Competency) ON 
COURSE.CourselD = COMPCOURSE.CourselD 
GROUP BY COMPCOURSE.Competency, CLASS.SSN 
ORDER BY CLASS.SSN; 

12. qryEMEShortCourses 



This query lists abbreviated courses in the EME syllabus ordered by course ID 
number. 



SELECT DISTINCTROW COURSE.CourselD, COURSE.CourseName, 

COURSE.Hours 

FROM COURSE 

WHERE ((COURSE.CourselD Like "*a")) 

ORDER BY COURSE.CourselD; 



13. qryOfficersbyCourselD 



This query lists the officers that have completed a particular course based on the 
course ID number selected. 



SELECT DISTINCTROW CLASS.SSN, OFFICER.LastName, OFFICER.UIC 
FROM OFFICER INNER JOIN CLASS ON OFFICER.SSN = CLASS.SSN 
WHERE ((CLASS.CourselD Like InputBox$("Enter a Course ID 
Number'V'CourselD"))); 
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14. qryWholeEnchilada 



This query lists all of the data pertinent to officers in the database based on UIC 
number or UIC name input. 



SELECT DISTINCTROW UIC.*, OFFICER.*, CLASS.*, COURSE.*, 
COMPETENCYCAT.*, COMPCOURSE.*, COMPCOURSE.* 

FROM (COURSE INNER JOIN ((UIC INNER JOIN OFFICER ON UIC.UIC = 
OFFICER.UIC) INNER JOIN CLASS ON OFFICER.SSN = CLASS.SSN) ON 
COURSE. CourselD = CLASS.CourselD) INNER JOIN (COMPETENCYCAT INNER 
JOIN COMPCOURSE ON COMPETENCY CAT.Competency = 

COMPCOURSE. Competency) ON COURSE.CourselD = COMPCOURSE.CourselD 
WHERE ((UIC.UIC Like InputBox$("Enter a Specific UIC or Press Enter for all 
Commands", "Command Name","") & "*")) 

ORDER BY UIC.UICName, OFFICER.LastName, OFFICER.FirstName, 
CLASS.CourselD; 
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APPENDIX G. PROTOTYPE SYSTEM REPORTS 



This appendix describes the pre-formatted reports currently available in the 
EMETRAK prototype system. 



1. Officers in Alphabetical Order (Figure G-l) 

This report provides a listing of all officers in the database in alphabetical order. 
The report prints the officer’s SSN, Name, Rank, Billet Sequence Code, Designator, Sub- 
specialty Code, Job Title, and UIC Name fields. The report is designed for program 
administration purposes in order to verify basic officer information contained in the 
database. 

2. Officers by UIC (Figure G-2) 

This report lists all of the officers in the database grouped by major command. 
The officers appear in alphabetical order under the appropriate command sub-head. The 
report is designed for program administration purposes to verify officer location and billet 
status. 

3. List of EME Courses (Figure G-3) 

This report lists all course modules available in the EME curriculum. The courses 
are ordered by course ID number. Course number, course title, course description, hours 
and course sponsor are printed in the body of the report. The total curriculum hours are 
summed at the end of the report. This report is designed for distribution as an 
abbreviated course catalog. 
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4. 



90-Day Class Report (Figure G-4) 



The 90-day Class Report is a listing of all course modules provided by the EME 
staff in the preceding ninety day period. The report lists all courses, the dates provided, 
and the officers that received the instruction. The report is designed as a program 
management tool to validate the course delivery schedule and verify data entry. 



5. Detailed Report in Alphabetical Order (Figure G-5) 

The detailed report lists all of the courses and hours completed by an individual 
officer based on the name or SSN input by the end-user. It is designed as an unofficial 
transcript for distribution to participating officers upon request. 



6. Courses by Competency (Figure G-6) 

This report lists EME courses grouped according to the DOD competency 
category. The course ID number, course title, and hours are listed in course number 
order. 



7. Detailed Report in Command Order (Figure G-7) 

This report is similar to the previously mentioned “alphabetical order detailed 
report’, except that the officers are grouped by command. The report will list a specific 
officer based on end-user selection or list all officers in the database. It is intended to 
provide a comprehensive listing of officers and their program history as a back-up paper 
record. 
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8 . 



Profiler (Figure G-8) 



The Profiler is an ad hoc report that allows the end-user to specify certain 
selection criteria. The user may choose the Designator, Rank, HSR, and Course ID of 
interest. In return, the report lists the officers in alphabetical order that meet the 
particular profile. 



9. List of Commands (Figure G-9) 

This report provides information about the commands in the database. The 
command UIC, command name, mailing address, telephone number, and HSR are listed. 



10. Course Completion Letter (Figure G-10) 

This report provides formal documentation about EME courses completed by an 
individual officer. The letters are generated soon after course completion information is 
entered into the database. The report is in standard naval letter format printed for the 
program coordinator’s signature. 



10. Completion Certificate (Figure G-ll) 

This report is a completion certificate that shows the number of CEU credits 
earned by the officer during a given period. The report is printed on color certificate 
paper and totals the number of CEU hours earned since the last certificate was issued. 
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Figure G-3 
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Figure G-4 
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Detailed Report in Alphabetical Order 
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Courses by Competency 



Competency: Acquisition Process 

Course ID Course Name 

38 Defense Acquisition Process and Health Care Implications 

Competency: Alternative Health Care Delivery Systems 

Course ID Course Name 

23 Alternative Health Care Delivery Systems 

Competency: Communication 

Course ID Course Name 

1 Understanding and Effectively Using Communication Media 

2 Communication Vision and Change in a Complex System 

3 Empowering Associates Through Strategic Feedback 

4 Bottom-Line and High Impact Health Care Communications 

5 Listening for Success 

6 Meeting Management 

47 Working in Teams 



Competency: Conflict Resolution 

Course ID Course Name 

44 Labor/Managment Relations/Negotiation in Health Care 

48 Conflict Management and Negotiation 



08-Apr-96 
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Figure G-7 
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Figure G-8 
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List of Commands 




Figure G-9 
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49871 HLTHCARE SUPPO JAX DET MIL 



From: 

To: 



Execuli ve Director, Institute for Defense Educat.on and Analysis, Naval Postgraduate School 
LCDR Paul Desmond, 012-38-4000 



Subj: EXECUTIVE MANAGEMENT EDUCATION PROGRAM MODULE COMPLETION 



' T !"! l6 n ef Certlfles that y° u have completed the requirements for the following 

part of the Executive Management Education Program: 



course module(s) as 



Number Course Title 
45 Leadership and Motivation 

Class Date: 7/27/95 Location: Camp Lejeune, NC 



Instructor Hours 

Crawford 6.00 



2 Questions concerning module completion should be directed to the EME Program Staff at the 
Naval Postgraduate School, commercial telephone (408) 656-2792 or DSN 878-2792 



S. R. Lamar, Ph.D. 
CAPT, MSC, USN (Ret) 



Figure G-10 




Figure G-l 1 
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APPENDIX H. PROTOTYPE SYSTEM FUNCTIONS 



This section contains Access Basic code for two of the major system functions 
that reside in the prototype’s module container. Additional coding was required to 
achieve the desired functionality, however, it was written as code behind the form (CBF) 
and is not included in this section. The functions were modified from examples listed in 
Reference 15. 



Function AutoExec () 'This function sets global properties for the prototype 

' application and takes the user to the Officer Record form 
' when the application file is opened. 

Const A_WINDOWMENU = 4 
Const A_HIDE - 3 

On Error GoTo AutoExec_Err 

Dim dbCurrent As Database 
Dim rstPreload As Recordset 
Dim intPreload As Integer 
Dim varRet As Variant 

DoCmd Hourglass True 

Application.SetOption "Built-In Toolbars Available", False 

If Not SysCmd(SYSCMD_RUNTIME) Then 

DoCmd SelectObject A_MACRO, "AutoExec", True 

DoCmd DoMenuItem A FORMBAR, A_WINDOWMENU, A_HIDE 

DoCmd OpenForm "ffmSplash" 

DoEvents 
End If 

Set dbCurrent = DBEngine.Workspaces(0).Databases(0) 

Set rstPreload = dbCurrent.OpenRecordset("qryPreload", DB_OPEN_SNAPSHOT) 

rstPreload.MoveLast 

intPreload = rstPreload. RecordCount 

varRet = SysCmd(SYSCMD_INITMETER, "EMETRAK is initializing...", intPreload) 
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intPreload - 1 



rstPreload.MoveFirst 
Do Until rstPreload.EOF 

DoCmd OpenForm rstPreload![FormName], , , , , A_HIDDEN 
varRet = SysCmd(S Y SCMD UPD ATEMETER, intPreload) 
intPreload = intPreload + 1 
rstPreload . MoveNext 
Loop 

DoCmd Close 

DoCmd OpenForm "OfficerRecord" 

AutoExec_Exit: 
rstPreload. Close 

varRet = SysCmd(SYSCMD_REMOVEMETER) 

DoCmd Hourglass False 
Exit Function 

AutoExec_Err: 

MsgBox "Error" & Err & " & Error$, 0, "AutoExec" 

Resume AutoExec Exit 

End Function 

Function QuitandExit_Click 0 This function resets normal Access properties 

'upon exit from the prototype application. 

On Error GoTo Err_QuitandExit_Click 

Application. SetOption "Built-in Toolbars Available", True 
DoCmd Quit 



Exit_QuitandExit_Click: 

Exit Function 

Err_QuitandExit_Click: 

MsgBox Error$ 

Resume Exit_QuitandExit_Click 
End Function 
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APPENDIX I. PROTOTYPE SYSTEM USER’S GUIDE 



A. INTRODUCTION 

EMETRAK is a powerful, yet easy to use windows-based database application. 
The application is designed to collect, maintain, and report EME program information 
and it accomplishes each of those functions with a minimum of key strokes or “clicks” of 
the mouse. EMETRAK has a simple graphical user interface and uses the “point and 
click” method for navigating within the database environment. A basic understanding of 
the Windows 3.0® or higher operating system is required and assumed as a starting point 
for using the EMETRAK system. EMETRAK is a Microsoft Access 2.0®-developed 
database application and therefore must be operated from within the Access application 
environment. 



B. LAUNCHING THE EMETRAK APPLICATION 



From Windows start Microsoft Access 2.0 by double-clicking on the Access 2.0 
icon. Once inside the Access application environment, open the EMETRAK application 
by clicking on the open folder icon or choosing “Open Database... ” from the “File” 
pull-down menu and selecting the EMETRAK application file (emetrak.mdb) from the 
appropriate directory (Figure 1-1). Double clicking on the file name (emetrak.mdb) or 
selecting the file and choosing OK will automatically launch the application. 



h=>l Vterosott Access 

Die Heip 






0|*?n Database 



hi 



emetratvmdb 






cAMHaaNNO*\«coM*\ecoi<<>< 




ewe data mdb 


♦ 




<b c.\ 

& msoflice 


- 








& access 
ft accdocs 
CD archive 






I 






nr 



U m m Xyp» 






| D diabases (* mdb) }~?| j Ml c. mt-do* A 



C f&*od (My 
F Cxdwtfc* 
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Figure 1-1. Open Database Window 

It normally takes several seconds for the application files to initialize and open. 
The EMETRAK application centers around the participating officer and, consequently, 
opens to the Officer Record form (Figure 1-2) as the main input screen. 
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C. WORKING WITH THE OFFICER RECORD FORM 

The Officer Record form serves as an interface between the system user and the 
data stored in the application’s database tables. Let’s take a moment to navigate around 
the form. 

There are several fields (or windows) on the form that contain information about 
the officer. The fields are: 

• SSN The officer’s social security number 

• Name The officer’s name (Last name , first name , middle initial) 

• Rank The officer’s rank (e.g. LCDR, CDR, etc.) 

• Service USN, USA, USAF, (USNR, etc. for reserve officers) 



Officer Record 




Officer Record 



■ 111 - 11-1111 



BOObG Desig 



Subspec 



l^rnT" 11 


Trrrr- 


E 


^Jt e st@tester 








1 Add Class | 


Tables | Reports 


| Competencies |/ 



* 

"ft 

nr 



Class Date Course ID Course Name 



Hours CEU Credits 



Spons*>— 



IB'j/ 


1 


Understanding and Effectively Using Communication Me 


TOO 


400 


NPS 




6/29/95B 


6 


Meeting Management 


’ 400 


4.00 


NPS 


1/1/95B 


6 


Stakeholder Management and Mapping the Health Care 


8.00 


8.00 


NPS 


9/19/951 


9A 


Stakeholder Management and Mapping the Health Care 


300 


300 


NPS 

NPS 


| 12/31/951 


13 


•Total Quality Leadership - The Application 


8.00 


8.00 


1/1/95| 


11 


Effective Information Systems 


400 


4.00 


NPS 


4 


y 1 


F+ 





Figure 1-2. Officer Record Form 



• Desig The officer’s designator or specialty code (2 1 00 - Medical Corps 
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(doctor), 2200 - Dental Corps (dentist), 2300 - Medical 
Service Corps (health care administrators, etc.), and 2900 - 
Nurse Corps (nurses)) 



• Sub-Spec The officer’s sub-specialty code (a four or five digit alpha- 

numeric) 

• BSC The officer’s billet sequence code (The officer’s job line 

number) 

• Job Title The officer’s English job title description. 

UIC The unit identification code (a five or six digit alpha- 
numeric) to which the officer is assigned. 

• Email The officer’s current electronic mail address 



The rank, service, and UIC fields are drop-down “pick” lists which make updating 
the field very easy. Simply click on the arrow next to the desired field and a list of 
choices drop down. Select the appropriate choice and the field is automatically updated. 
Note: Information in these fields can be entered through the keyboard as well as selecting 
from the “pick” list. You should save the record after modification to ensure that the 
database will be updated. 

There are several “action buttons” on the Officer Record form. Each button 
performs a specific function or displays information from the database tables. 



I,. I The “Display UIC” button (next to the UIC field) displays the officer’s 
unit mailing address and unit telephone number when it is clicked. Information on this 
pop-up form is read only and can not be modified from this form. Modifications to this 
information will be discussed in a later section. 

The group of buttons on the right side of the Officer Record form allows the user 
to navigate from one officer record to another and perform basic file operations. 



— I — I The “Add Officer” button allows the user to enter a new officer record. When it 
is clicked, all of the fields on the current Officer Record form clear and are ready for new 
information to be entered. An alternate method of adding a new officer record is through 
the “New” sub-menu under the “Records” pull-down menu. 






The “Save” button writes (or saves) the newly added or modified information to 
the database. Note: If the save button is not clicked after information on the form has 
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been modified, the new items will not be added to database. An alternate method of 
saving a newly added record is through “Save Record” under the “File” pull-down menu. 



1 The “Search” button uses the standard Windows “Find” function. First, click on 
the desired field to search. Then click the ’’Search” button. The button opens the 
Windows “Find” dialog box (Figure 1-3). 




Figure 1-3. Find Input Box 

Once in the “Find” dialog box, enter the string of letters or numbers as required in 
the “Find What” field (such as the SSN 111-11-1111 depicted in the figure) and select the 
“Find First” button to initiate a search for the appropriate record. Close the “Find” dialog 
box once the search has found the appropriate record. 



The “Find” function can also be selected through the application menu structure 
by choosing “Edit” and ‘Find”. Note: The “Find” dialog box will retain the data entered 
until you exit the application even if the dialog is closed and later reopened. 



QE 



The “Delete” button is used to remove an officer record that has been incorrectly 
entered. Note: If an officer record exists in the database and has classes assigned to it, the 
application’s database integrity rules will prevent deletion of that officer record. 



L^LJ jU The “Navigation Arrows” allow the user to move from one record to the 
next. The officer records are ordered in ascending (least to greatest) order by SSN as a 
default. The records can be re-arranged in alphabetical order by last name as specified by 
the user. To arrange the officers in alphabetical order click on the desired field (last 
name), then select “Ascending” from the “Quick Sort” sub-menu under “Records 44 pull- 
down menu. 

The buttons arranged along the middle of the Officer Record form allow the user 
to access other program information related to the Officer Record form. 
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Add Class 



Clicking on the “Add a Class” button opens the “Add a Class” pop-up 



form and allows the user to enter a new class for the officer. 



Tables 



The “Tables” button takes the user to a table switchboard, from which, the 
user may view and/or modify data directly in the Course Modules, Competency 
Categories, or UIC database tables. 



Reports j “R e p or t s ” button takes the user to a report switchboard, from which, 
the user can select system reports for preview or print. 



, Competencies | Clicking on the “Competencies” button allows the user to view the 
officer’s completed EME hours grouped according to competency category. 



The lower portion of the Officer Record form contains a sub-form which displays 
the classes completed by the officer (Figure 1-4). This section is “read-only” and can not 
be modified on the Officer Record form. The scroll bars next to the information, 
however, allow the user to view all course information related to the officer. 



Class Date 


Course ID 


Course Name 


Hours CEU Credits 


Sponsc 






1 


Understanding and Effectively Using Communication Me 


4 00 


400 


NPS 


— 


6/29/95 


6 


Meeting Management 


400 


400 


NPS 




1/1/95 


9 


Stakeholder Management and Mapping the Health Care 


8.00 


8.00 


NPS 




9/19/95 


9A 


Stakeholder Management and Mapping the Health Care 


3.00 


3.00 


NPS 




12/31/95 


13 


Total Quality Leadership - The Application 


8.00 


8.00 


NPS 




1/1/95 


18 


Effective Information Systems 


400 


400 


NPS 


4 



Figure 1-4. Class Subform 




D. 



ADDING A CLASS 



Using the “Add New Class” form is the only way to add a new class occurrence 



to an officer’s record. Clicking on the , button opens the “Add New Class’ 

form (Figure 1-5). 



147 







Figure 1-5. Add New Class Form 



To add a new class, click on the “Add” button 1 and all of the form’s data 

fields will clear. Click on the SSN field, type the officer’s SSN, and press enter. The 
officer’s name will automatically appear next to the Name: label if the SSN has been 
entered correctly. The user jumps to the next field by pressing enter after typing in the 
information. 



The course text box uses a “pick” list which, when selected, shows all of the EME 
course modules. Course modules may be entered by selecting the appropriate entry from 
the “pick” list or by typing the number in the text box. 

For multiple class entries, such as from a course completion roster, the user can 
easily enter information on many officers right from the same “Add a Class” form. The 
user simply enters a new SSN and course number and then double clicks in the other 
fields on the form to paste the previously entered information in the appropriate text box. 
This method significantly speeds up class roster data entry. 



To delete an incorrect entry use the “Delete” button 
correct information. 




and re-enter the 



The “Close” button 




returns the user to the Officer Record form. 
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E. 



SYSTEM TABLES 



Clicking the 



Tables 



Switchboard (Figure 1-6). 



button on the Officer Record form opens the Table 



Form: T ableSwitchboard 



1 1 


! K 




Course 




Competencies 


h= 








KB' : 


IHI tS 




m 




«-♦ 



Figure 1-6. Table Switchboard 

Selecting any of the three buttons (Course, Competencies, or UIC) opens the 
appropriate database table. Information in each the database table (Figure 1-7) may be 
added, modified or deleted subject to the application database integrity rules. 



Table: COURSE 




Course Name - j Hours 1 CEU Crgj Co urse Sponsor] 

Understanding and Effectively Using Com nr 4.00 4JHXNPS 

Communication Vision and C h ange in a Cor 4.00 4.00 NPS 





3 


Empowering Associates Through Strategic 


4.00 


4 00 NPS 




4 


Bottom-Line and High Impact Health Care C 


8.00* 


8.00 NPS 




5 


Listening for Success I 


4.00 


4 00 NPS 




6 


Meeting Management 


4.00 


4.00 NPS 



Figure 1-7. Database Table 



The “Close” button takes the user back to Officer Record form. 



F. SYSTEM REPORTS 



EMETRAK has ten pre-formatted reports. To access EMETRAK system reports, 
the user selects the “Reports” button on the Officer Record form. This event opens the 
“Select a Run” switchboard menu (Figure 1-8). 
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Form: SelectaRun 




Select a Run 



All Officers in Alphabetical Order 


1 


* 


Officers Grouped by Command 


2 




List of All Modules (with descriptions) 


3 




Classes Given in the Last 90 Days A 

Modules Completed by a Specific Officer 5 
List of All Modules by Competency 6 

Officers and Completed Modules Grouped t 7 




Profiler 


8 







' . ' “:<y~ 

l^ueryj 






Print Preview 






Print 






* 





Figure 1-8. Reports Switchboard 

The “Select a Run” switchboard allows the user to select from one of the ten pre- 
formatted reports in either query view (tabular format), print preview mode or printed 
format. 



Select the desired report by clicking on the report title and clicking on either of 
the three action buttons (query, print preview, or print). Some reports require a more 
refined selection criteria (e.g. specific SSN or name) and will prompt the user for more 
input. The user enters the desired criteria through the use of a dialog box similar to 
Figure 1-9. Once the user provides the criteria and presses enter the report can either be 
viewed or printed depending on the selection. 




Figure 1-9. Input Box 

The “Close” button returns the user to the Officer Record form. 
G. VIEWING OFFICER COMPETENCIES 



Selecting the 



Competencies 



button opens the officer’s Competency Count 
form (Figure I- 10). The Competency Count form shows the number of hours that the 
officer has completed grouped by EME competency category. 
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Managing Change & Tech Innovati 1 



12 



Figure 1-10. Competency Count Form 

Close the Competency Count form by double-clicking on the minus (-) sign in the 
upper left comer of the form. 



H. CLOSING THE APPLICATION 



fit I 

y .I 1 Clicking on the “Exit” button on the Officer Record form closes the 

EMETRAK application. However, before the application completely closes down, the 
user is presented with a dialog box which asks if you desire to back up the database 
(Figure 1-1 1). 



Back Up or Exit 



Would you like to back up the database? 




Figure 1-11. Exit Dialog Box 

Selecting “Yes” on the Back Up or Exit dialog box starts the back up procedure. 
The back up procedure takes several minutes and requires that you insert 1 .44 MB floppy 
disks in drive a: when prompted. After the the back up procedure is completed, select 
“OK” in the appropriate message box and the application will close normally. If “No” is 
selected in the Back Up or Exit dialog box, the EMETRAK program automatically 
closes out to the Windows desk top. The alternate method of closing the EMETRAK 
application is by selecting “Exit” from the “File” pull-down menu. This method by- 
passes the back up procedure. 
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EXIT TO SYSTEM 



APPENDIX J. MULTI-USER SYSTEM STATE 
TRANSITION DIAGRAMS 
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EXIT TO SYSTEM 

Figure J-l. Enterprise and Program Management Views 




Organizational Program Mgt 

View View 
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APPENDIX K. STATISTICAL REPORT FORMATS 



This appendix provides sample formats for the different types of statistical presentations 
required in the EMETRAK multi-user system. 




Figure K-l. Line Graph Format 



Percentage of Total Officers Who 
Have Completed Module 9 by HSR 




Figure K-2. Pie Chart Format Format 
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Courses by Provider 
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Courses 



Figure K-3. Bar Graph Format 
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